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ABSTRACT 


The  move  toward  e-government  has  seen  many  institutions  put  speeial  focus  on 
the  need  for  security,  especially  that  of  authentication.  Single-factor  password-based 
systems  have  been  proven  inadequate  in  safeguarding  online  financial  and  e-government 
service  transactions.  Industry  adoption  of  Two-Factor  Authentication  (2FA)  has  also  been 
piecemeal.  To  mitigate  these  deficiencies,  the  Singapore  Government,  in  2008,  put  forth  a 
Call-for-Collaboration  (CFC)  seeking  industry  and  academic  participation  in  defining  a 
National  Authentication  Framework  (NAF),  with  the  dual  aim  of  providing  for  a 
national-level  2FA  system  and  broadening  the  market  for  authentication  services,  and,  in 
so  doing,  providing  the  user  with  a  better  authentication  experience.  This  thesis  will 
detail,  discuss,  and  compare  the  various  token  types  and  identity  frameworks  (PKI, 
SAML,  WS-F,  OpenID,  and  Infocard)  that  make  up  an  authentication  system,  and  make 
recommendations  on  the  best  combination  of  technologies,  protocols,  and  standards  that, 
when  implemented,  would  not  only  fulfill  the  requirements  of  the  CFC,  but  also  position 
it  well  for  future  enhancement. 
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EXECUTIVE  SUMMARY 


The  National  Authentication  Framework  (NAF)  Call-for-collaboration  (CFC)  was 
launched  in  2008  as  part  of  the  Singapore  Government’s  plan  to  provide  for  a  national- 
level  Two-factor  Authentication  (2FA)  system,  broaden  the  market  for  authentication 
services,  and  enhance  the  user  experience.  The  CFC  calls  for  proposals  from  industry  and 
academia  for  a  standards-based  system  that  would  permit  the  user  the  choice  of 
Authentication  Operator  (AO)  and  token  type  used  to  access  an  online  service.  Two 
requirements  listed  will  have  significant  impact  on  the  final  proposed  implementation 
model;  The  first  is  that  non-repudiation  is  to  be  a  feature  of  the  system,  and  the  second  is 
that  all  proposed  technologies  must  have  received  recognition  as  a  standard.  These 
requirements  serve  as  assessment  criteria  in  the  analysis  and  selection  of  token  types  and 
identity  frameworks  that  would  best  serve  the  NAF. 

The  requirement  for  non-repudiation  impacts  the  choice  of  token  type:  Only 
asymmetric  cryptographic  keys  would,  when  implemented  with  Public  Key  Infrastructure 
(PKI)  in  place,  offer  non-repudiation  through  the  application  of  digital  signatures  to 
online  transactions.  Other  token  types  possess  no  such  characteristic  and  are  thus 
relegated  to  transactions  that  do  not  require  non-repudiation.  That  the  proposed  model 
incorporates  only  recognized  standards  limits  the  choice  of  identity  framework  to  the 
Security  Assertion  Markup  Language  (SAML)  v2.0  standard.  It  is  fortunate,  though,  that 
the  SAML  v2.0  standard  also  excels  in  all  other  assessment  criteria,  including  being  fit- 
for-purpose,  supporting  proxy  authentication  and  maintaining  user  anonymity. 

The  proposed  implementation  model,  incorporating  both  PKI  and  SAML  v2.0  as 
the  underlying  identity  framework,  and  the  choice  of  the  asymmetric  cryptographic  token 
for  its  supportability  of  non-repudiation  is,  in  the  author’s  opinion,  the  best  possible 
combination  of  technologies  that  would  not  only  fulfill  the  requirements  of  the  NAF,  but 
also  position  the  NAF  well  for  future  enhancements.  That  last  consideration  is  especially 
critical  when  considering  the  amount  of  resources  expected  to  be  expended  on  such  a 
major  effort. 

xvii 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


ACKNOWLEDGMENTS 


This  work  is  dedicated  to  my  wife,  Melisse,  who  has  been  my  greatest  supporter. 

I  would  also  like  to  thank  Dr  Bert  Lundy,  and  John  Fulp,  for  their  advice  and 
guidance. 

And  thanks  to  God,  who  makes  all  things  possible. 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


XX 


I.  INTRODUCTION 


A,  THESIS  BACKGROUND 

The  desire  to  reduee  bureaucraey,  and  to  better  engage  the  general  population,  are 
two  of  the  reasons  that  have  led  numerous  governments  to  embark  on  programs  that 
would  see  traditional  serviees  being  made  aeeessible  online.  The  ten-year  Intelligent 
National  Masterplan  (iN2015)  to  be  implemented  by  the  Infoeomm  Development 
Authority  of  Singapore  (IDA)  is  one  sueh  program.  To  date,  nearly  370  online 
Government-to-business  (GtoB)  and  Govemment-to-eitizen  (GtoC)  serviees  have  been 
made  available  [1],  joining  the  substantial  number  of  e-banking  serviees  already 
available.  This  proliferation,  however,  has  led  to  a  greater  frequeney  of  malieious 
aetivities.  Beeause  of  this,  as  well  as  the  inerease  in  the  sophistieation  of  attacks  being 
performed,  there  is  a  definite  need  for  stronger  forms  of  protection  for  online 
transactions.  To  increase  this  protection,  among  the  many  initiatives  that  are  part  of 
iN2015,  is  the  development  of  a  National  Authentication  Framework  (NAF).  The  aim  of 
the  NAF  is  to  [2]: 

1.  “Enable  consistent  strong  authentication  for  end-users  accessing  key 
online  services;”  and 

2.  “Make  the  process  of  authenticating  online  identities  more  vigorous, 
thereby  boosting  online  trust  and  confidence  in  individuals  accessing  the 
next  generation  of  online  services.” 

B,  AUTHENTICATION:  A  DEFINITION 

Authentication  is  defined  as  the  verification  of  the  “identity  of  a  user,  process,  or 
device,  often  as  a  prerequisite  to  allowing  access  to  resources  in  an  information  system” 
[3].  Authentication  is  a  constituent  component  of  integrity,  itself  defined  as  the  process  of 
“guarding  against  improper  information  modification  or  destruction,  and  includes 
ensuring  information  non-repudiation  and  authenticity”  [3].  Integrity  is  a  component  of 
the  Information  Assurance  (lA)  confidentiality,  integrity,  and  availability  (CIA)  triad 
which  constitutes  the  core  principles  of  information  security  [4]. 
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Authentication  is  accomplished  through  one  of  the  following:  1)  demonstrating 
knowledge  of  a  shared  secret,  or  “something  the  user  knows”;  2)  presentation  of  an 
authorized  token,  or  “something  the  user  has”;  or  3)  presentation  of  a  unique  physical 
characteristic,  or  “something  the  user  is.”  These  proofs  of  identity  are  collectively  known 
as  factors  of  identity.  The  withdrawal  of  cash  from  an  automated  teller  machine  (ATM) 
illustrates  the  use  of  factors  of  identity.  A  user  presents  his  ATM  card  token,  “something 
the  user  has,”  either  through  swiping  or  insertion,  followed  by  the  input  of  his  personal 
identification  number  (PIN),  “something  the  user  knows,”  onto  a  keypad  in  order  to 
proceed  with  the  transaction.  In  Japan,  users  are  obliged  to  additionally  present  either  the 
thumb  or  index  finger  to  a  scanner  as  a  further  form  of  identification,  “something  the  user 
is.”  There  have  been  efforts  at  identifying  additional  factors  for  authentication,  including 
“someone  the  user  knows”  [5],  but  the  latter  is  of  limited  use  in  non-contact  situations. 

The  use  of  Single-factor  Authentication  (SFA)  in  the  form  of  a  password  or  PIN 
for  authentication  is  prevalent  in  the  majority  of  online  transactions.  The  continued 
reliance  on  SFA  has  been  advised  against  in  view  of  the  relative  ease  with  which  such 
authentication  means  can  be  subverted.  A  prominent  case  in  Singapore  involved  the 
compromise  of  21  Post  Office  Savings  Bank  Internet  banking  accounts  in  June  2002  [6]. 
This  led  to  the  voluntary  conversion  to  a  Two-factor  Authentication  (2FA)  system  in 
May  2003  [7]  with  the  addition  of  a  hardware  One-time  Password  (OTP)  token,  a  first  in 
the  region  at  the  time.  The  Federal  Financial  Institutions  Examination  Council  (FFIEC), 
having  recognized  the  inadequacy  of  SEA,  had  also  suggested  that  financial  institutions 
adopt  multi-factor  authentication  in  order  to  mitigate  the  risks  of  account  fraud  and 
identity  theft  [8]  in  2002. 

Two-factor  Authentication  methods  are  aimed  particularly  at  overcoming  the 
shortcomings  of  password-only  SEA  methods,  and  are  effective  against  passive  forms  of 
malicious  attacks.  Against  active  attacks,  however,  certain  forms  of  2EA  unfortunately 
are  not  as  effective  [9].  The  choice  of  biometrics,  or  “something  the  user  is”  type  tokens, 
as  a  factor  for  remote  authentication,  is  limited.  Thus,  biometric  authentication  is  better 
suited  for  local  use,  whereby  the  user  presents  a  livesample  of  his  physical  characteristic 
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for  on-site  comparison  against  his  previously  registered  copy  without  going  through  a 
network  [10].  The  selection  of  the  type  of  2FA  method  is,  then,  particularly  crucial  in 
order  to  sustain  secure  online  transactions. 

C.  NAF:  IMPETUS,  BENEFITS,  AND  CHALLENGES 

Current  access  to  online  government  services  is  through  password-based  SFA 
means,  locally  referred  to  as  SINGPASS.  This  restricts  the  number  of  services  available 
online  to  those  that  require  relatively  low  assurance.  In  the  financial  sector,  2FA  has  been 
implemented  to  a  large  extent  in  a  stove-piped  manner,  resulting  in  consumers  having  to 
manage  separate  tokens  for  each  institution  with  which  they  have  a  relationship;  e.g.,  a 
user  may  use  a  hardware  OTP  token  for  transactions  with  Institution  A  but  rely  on  Out  of 
Band  short  messaging  system  (SMS)— based  tokens  for  transactions  with  Institution  B. 
The  number  of  tokens  that  may  potentially  be  required  to  be  in  a  user’s  possession  will 
grow  as  more  institutions  adopt  strong  authentication  mechanisms.  The  continuance  of 
the  current  stove-piped  system  will  make  token  management  cumbersome. 

With  the  more  interoperable  NAF  implemented,  the  Singapore  government  aims 
to  put  in  place  an  infrastructure  that  not  only  strengthens  the  authentication  process, 
particularly  through  the  addition  of  a  second  authentication  factor  for  online  government 
services,  but  also  streamlines  the  user  experience  for  consumers.  That  is,  a  consumer  may 
choose  to  possess  a  single  token  acceptable  for  all  online  transactions  or  may  choose  to 
be  selective  as  to  the  number  of  tokens  he  or  she  possesses  and  also  as  to  with  which 
institutions  each  token  will  be  affiliated.  Any  number  of  reasons  may  govern  the 
consumer’s  choice  of  token  type  and  affiliation,  including  that  of  per-transaction  cost, 
hardware  and  software  requirements,  or  user  convenience.  Even  more  important  is  that 
the  token  must  be  acceptable  to  the  relying  institution  based  on  a  predetermined  level  of 
assurance  afforded  by  characteristics  of  the  token  type  and  its  concomitant  infrastructure 
and  administration.  This  requirement  for  choice  will  engender  the  growth  of  a  market  in 
strong  authentication  services.  With  a  larger  consumer  base,  as  compared  to  previous 
implementations,  which  were  limited  to  a  single  institution’s  clientele,  consumers  will 
benefit  through  overall  lowered  costs  as  a  result  of  economies  of  scale  and  competition. 
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Relying  institutions  will  also  no  longer  need  to  maintain  their  own  private  authentieation 
infrastructure,  but  can  instead  outsource  such  to  institutions  better  equipped  for  meeting 
the  ever-changing  nature  of  technology,  as  well  as  dealing  with  the  associated  risks.  To 
enable  this  market,  and  to  allow  for  a  level-playing  field,  however,  any  implementation 
must  be  standards-based;  and,  hence,  it  is  part  of  the  NAF’s  scope  to  ensure  that  proposed 
solutions  are  interoperable. 

D,  THESIS  OUTLINE 

Based  upon  the  requirements  set  forth  by  the  CFC  document  for  the  NAF, 
coupled  with  an  in-depth  look  into  the  current  state  of  the  art  in  terms  of  authentication 
methods  and  protocols,  this  thesis  aims  to  suggest  a  framework  model  that  would  be 
suited  not  just  to  fulfdling  the  requirements,  but  to  ensuring  that  the  derived  system  is 
well  positioned  to  meet  future  challenges.  This  will  be  achieved  first  by  illustrating  with  a 
use  case  the  interactions  between  the  principal  actors  throughout  the  authentication 
process;  this  use  case  will  serve  as  a  baseline  reference  in  Chapter  II.  An  analysis  of  the 
various  types  of  authentication  tokens  and  associated  form  factors,  as  well  as  supporting 
authentication  frameworks,  will  be  detailed  in  Chapters  III  and  IV,  respectively.  In 
Chapter  V,  the  best-fit  components  identified  in  previous  chapters  will  be  amalgamated 
into  a  system  in  compliance  with  the  requirements  of  the  NAF,  illustrated  by  a  use  case 
depicting  how  the  proposed  framework  supports  authentication.  The  thesis  will  conclude 
with  Chapter  VI,  which  details  how  system  requirements  affect  the  overall 
implementation  design  and  the  possible  implications. 
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II.  AUTHENTICATION  USE  CASE  MODEL 


A,  OVERVIEW 

From  a  user  perspective,  the  authentication  process  as  typified  by  the  presentation 
of  a  user  ID  and  password  is  a  familiar  one.  The  underlying  exchange  of  data  to  enable 
authentication,  however,  is  anything  but  simple.  The  complexity  derives  from  the  number 
of  parties  involved,  inter-party  interactions,  and  other  associated  factors.  Prior  to  deriving 
the  technical  implementation,  a  use  case  model  depicting  these  interactions  will  be 
developed  to  serve  as  a  basis  for  the  selection  of  the  most  appropriate  supporting 
technologies.  The  use  case  itself  will  be  developed  from  a  functional  model  that  details 
the  functions  of  each  actor  in  the  use  case. 

B,  USE  CASE  ACTORS 

An  actor  represents  a  party  to  the  transaction,  e.g.,  a  customer  or  a  bank.  The 
actors  of  an  authentication  can  be  specified  based  on  their  roles  in  the  process  [10],  or  as 
abstractions  for  the  actual  system  users  in  a  specified  scenario  [2].  Greater  clarity  is 
achieved  through  role  separation;  to  achieve  congruency  with  the  CFC,  however,  the 
actors  will  be  specified  in  terms  of  actual  abstractions  from  the  perspective  of  the 
provision  of  a  service.  Where  necessary,  the  description  of  each  actor  will  include  the 
roles  each  encompasses.  Although  typical  implementations  of  authentication  mechanisms 
see  the  involvement  of  only  two  actors,  i.e.,  the  actor  requesting  a  service  and  the  actor 
providing  the  service,  a  third  party  may  be  necessary  as  an  intermediary  if  one 
authentication  mechanism  is  used  by  the  one  actor  to  access  services  provided  by  more 
than  one  other  actor.  The  three  principle  actors  in  the  authentication  process  are  as 
follows. 

1.  Authentication  Operators 

An  Authentication  Operator  (AO)  is  a  provider  of  strong  authentication  services, 
inclusive  of  functional  and  managerial  responsibilities,  deemed  necessary  for  the  proper 
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administration  of  credentials.  AOs  are  also  otherwise  known  as  “Credential  Service 
Provider,”  “Credential  Issuer,”  and  “Verifier”  [10],  [11].  The  term  credential  is  used  in 
this  instanee  to  define  an  “object  that  authoritatively  binds  an  identity  to  a  token 
possessed  and  eontrolled  by  a  person”  [10]  or,  in  shorter  parlanee,  a  verified  token,  sueh 
as  an  authorized  smart  card  issued  by  the  bank.  Verisign  is  but  one  example  of  an  AO.  In 
partieular,  Verisign  provides  digital  eertifieation  serviees  to  Web  sites. 

2.  Service  Providers 

A  Service  Provider  (SP)  is  a  provider  of  online  serviees  to  service  consumers.  SPs 
rely  on  AOs  to  authenticate  users  prior  to  providing  services  to  the  users.  SPs  are 
alternatively  termed  “Relying  Parties”  [10].  In  the  context  of  this  thesis,  SPs  are 
government  agencies  and  other  institutions,  both  public  and  private,  that  support  online 
transactions. 


3.  Users 

Users  are  subscribers  to  online  services,  e.g.,  citizens,  residents.  Users  are  most 
typically  the  initiators  of  an  online  transaction.  Since  it  is  the  user’s  identity  that  requires 
verification,  the  user  is  alternatively  also  commonly  described  as  a  “Claimant”  during  the 
authentication  process  because  the  user  is  making  a  claim  regarding  his  identity. 

C.  AUTHENTICATION  COMPONENT  FUNCTIONS 

Several  functions  have  been  identified  that  are  necessary  to  actualize  the 
authentication  processes.  The  functions  have  been  adapted  from  the  Australian  National 
E- Authentication  Framework  (NEAF)  [11].  The  functions  are  executed  by  the  actors  at 
specific  points  of  the  authentication  process,  making  up  the  Functional  Implementation 
Model. 


1.  User  Registration 

The  user  registration  function  represents  the  processes  associated  with  the  initial 
creation  of  an  electronic  identity  (e-identity)  for  a  user,  encompassing  Evidence  of 
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Identity  (EOI)  or  Evidence  of  Relationship  (EOR)  processes,  e.g.,  the  selection  of  an 
online  identifier  (user  ID)  when  registering  for  a  new  bank  account  at  a  bank’s  branch 
office  by  physically  providing  one’s  SSN  and  a  valid  driving  license  as  proof  of  one’s 
identity. 

2.  Token  Issuance  (and  Management) 

A  token  is  “something  that  the  Claimant  possesses  and  controls  used  to 
authenticate  the  Claimant’s  identity”  [10].  A  token  is  provided  to  the  user  for  subsequent 
online  authentication  transactions.  No  token  is  perpetual,  and  the  issuing  agency  is 
responsible  for  ensuring  the  validity  of  the  token  throughout  its  life  cycle  and  for  any 
subsequent  mitigation  actions  required,  should  a  malfunction  occur.  Examples  of  a  token 
include  a  sealed  envelope  containing  the  user’s  PIN,  or  an  OTP  key-fob.  Greater  detail  on 
the  types  and  characteristics  of  various  tokens  will  be  undertaken  in  the  next  chapter. 

3.  User  Enrollment 

User  enrollment  refers  to  the  act  of  binding  an  authentication  token  to  a  known 
instance  of  a  user  identity  within  an  Information  Technology  (IT)  resource  context, 
resulting  in  establishing  a  credential.  Eor  example,  a  credential  is  created  when  a  user 
initially  logs  into  the  bank’s  Web  site  with  a  user  ID  and  PIN,  then  registers  the  OTP  key- 
fob  by  entering  the  unique  key-fob  serial  number  into  the  bank’s  Web  page;  those  actions 
cause  the  unique  key-fob  to  be  associated  with  the  user’s  account. 

4.  Credential  Verification 

Credential  verification  is  the  verification  of  an  enrolled  token,  which  takes  place 
as  a  precursor  to  enabling  the  conduct  of  a  transaction.  It  encompasses  the  issuance  of  a 
positive  identity  indicator,  known  as  an  assertion,  to  a  requesting  SP.  Eor  example,  a 
bank’s  Web  page  will  seek  entry  of  the  OTP  from  the  user’s  key-fob  (i.e.,  the  token)  for 
verification  of  the  user’s  identity  prior  to  servicing  the  user’s  request.  The  term  credential 
is  used  in  this  context,  as  opposed  to  token:  the  token  would  have  been  enrolled  and 
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bound  to  an  identifier,  prior  to  the  need  for  verifieation.  Validation,  which  relates  to  the 
checking  of  the  status  of  the  credential  at  the  time  of  verification,  is  implied. 

D.  FUNCTIONAL  MODEL  DEVELOPMENT 

1,  Overview 

This  section  defines  a  functional  model  specification  incorporating  the  defined 
component  functions.  Three  existing  models — Siloed,  Centralized,  and  Federated — are 
first  described.  Selection  criteria  are  presented  against  which  the  models  are  analyzed.  A 
fourth  model.  Interoperable,  is  thereafter  developed  based  on  the  existing  models,  with 
augmentation  based  on  the  established  selection  criteria. 

2,  Functional  Models 

Three  functional  models  have  been  identified  in  support  of  authentication — 
Siloed,  Centralized,  and  Federated  [11].  Each  model  differs  primarily  in  the  actor 
responsible  for  the  provision  of  component  functions.  The  details  of  the  three  models  are 
captured  in  Figure  1,  and  explained  below. 


SILOED 


CENTRALIZED 


FEDERATED 


D 


Figure  1 .  Functional  Implementation  Models.  After  [11] 


8 


a. 


Siloed 


This  model  is  representative  of  eurrent  authentieation  meehanisms  being 
deployed  by  major  finaneial  institutions  in  Singapore.  All  eomponent  funetions  are 
provided  by  the  SP.  Individual  institutions  eontraet  separately  for  the  proeurement  and 
establishment  of  in-house  proprietary  authentieation  meehanisms  [12],  [13].  This  results 
in  individuals  possessing  multiple  authentieation  tokens,  one  for  eaeh  institution  with 
whieh  the  individual  has  a  relationship.  As  this  model  eliminates  the  need  for  AOs,  it 
results  in  a  simpler  transaetional  proeess,  as  well  as  the  fastest  transaetions.  The  need  for 
in-house  infrastrueture,  though,  would  require  high  initial  eapital  outlay,  as  well  as 
eontinuous  life-eyele  eosts,  whieh  may  prove  to  be  a  barrier  to  entry  for  all  but  the  largest 
institutions.  The  model  does  not  benefit  from  eeonomies  of  seale. 

b.  Centralized 

This  model  sees  a  user  registering  with  an  AO  for  the  provision  of  a  global 
identifier  and  a  token.  The  user’s  eredentials  (global  identifier  and  token)  are 
subsequently  enrolled  with  eaeh  SP.  When  a  user  requires  a  serviee,  the  user  presents  his 
eredentials  to  the  SP,  whieh  will  subsequently  be  redireeted  to  the  AO  for  verifieation.  As 
authentieation  serviees  are  outsoureed,  SPs  no  longer  need  bear  the  eosts  involved  in 
maintaining  in-house  systems.  The  eost  to  both  SP  and  the  individual  is  redueed  in  light 
of  the  shared  infrastrueture.  Individuals  may  also  have  a  ehoiee  in  the  form  faetor  and 
method  of  authentieation.  Coneerns  inelude  the  monopolistie  dominanee  of  a  single 
provider,  a  single  point  of  failure,  inereased  transaetion  time,  and  privaey  issues  arising 
from  having  a  global  identifier  registered  aeross  all  SPs. 

c.  Federated 

The  Federated  Model  differs  from  the  eentralized  model  in  that  there  is  no 
requirement  for  a  global  identifier.  The  AO  is  responsible  only  for  the  issuanee  of  the 
token.  The  user  enrolls  the  provided  token  with  the  SP;  the  token  and  its  attributes  will  be 
assoeiated  with  the  user’s  unique  identifier  with  the  SP,  resulting  in  a  eredential.  Eaeh 
time  the  user  requires  a  serviee,  the  user  presents  his  or  her  eredential  to  the  SP,  whieh 
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will  request  separate  verifieation  of  the  attaehed  token  from  the  AO.  Positive  verification 
is  communicated  back  to  the  SP  from  the  AO  in  the  form  of  an  assertion.  This 
mechanism  serves  as  the  basis  for  Single  Sign-on  (SSO),  which  translates  to  greater  user 
convenience  because  only  a  single  authentication  process  is  required  to  access  multiple 
SPs,  assuming  that  all  relying  SPs  have  a  relationship  with  the  same  AO.  The  Federated 
Model  provides  an  additional  layer  of  privacy  to  the  consumer.  There  is  no  global 
identifier,  as  with  the  Centralized  Model,  resulting  in  there  being  less  risk  of  associating 
contents  from  different  SPs  to  the  same  user.  Initial  transaction  duration  is  expected  to  be 
longer  as  a  result  of  the  greater  complexity  of  the  SSO  operation;  but  overall  performance 
would  be  greatly  enhanced. 

3,  Selection  Criteria 

With  most  systems  already  implementing  the  Siloed  Model,  the  emphasis  of  the 
NAF  would  be  the  implementation  of  a  system  whereby  more  commonality  could  be 
achieved.  The  decision  as  to  whether  a  centralized  or  federated  model  would  be  better 
suited  to  the  NAF  would  be  dependent  upon  the  requirements  as  laid  out  in  the  CFC. 
Three  important  requirements  have  been  identified. 

a.  Criterion  #1 

Cross-authentication  of  individuals/SPs  is  to  be  enabled  across  AOs,  e.g., 
an  individual  A  utilizing  AO  X  will  be  able  to  utilize  services  provided  by  SP  B,  utilizing 
AO  Y  without  a  noticeable  degradation  in  performance. 

b.  Criterion  #2 

Implemented  systems  should  incorporate/build  upon  current  systems,  i.e., 
they  should  support  SP-specific  user  ID  and  password/PIN  as  the  first  authentication 
factor  in  a  2FA  implementation. 
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c.  Criterion  #3 

Users  will  have  a  ehoiee  of  AOs,  token  type,  and  form  faetor  employed  for 
authentication.  Accordingly,  each  SP  may  determine  the  minimal  level  of  assurance 
necessary  to  access  its  services,  translating  to  which  of  the  various  methods  would  be 
acceptable  to  the  SP  as  an  authentication  means. 

4.  Analysis 

The  characteristics  of  the  centralized  and  federated  models  were  compared  based 
upon  the  criteria  developed  in  the  previous  subsection.  The  results  of  the  comparison  are 
discussed  below: 


a.  Criterion  #1 

In  the  Centralized  Model,  with  only  a  single  AO,  there  is  no  requirement 
for  cross-authentication.  For  the  Federated  Model,  the  use  of  Persistent  Pseudonymous 
Identifiers  (PPI)  may  be  necessary  between  AO  X  and  AO  Y,  and  between  AO  X  and  SP 
B,  in  order  to  ensure  that  the  generated  assertion  can  be  mapped  to  the  user  at  the  SP  end. 

b.  Criterion  #2 

In  terms  of  criteron  2,  for  the  Centralized  Model,  the  use  of  a  global 
identifier  may  require  a  PPI  to  map  currently-existing  IDs  with  SPs  to  the  new  global 
identifier.  The  nature  of  the  Federated  Model  supports  this  requirement  organically,  since 
users  can  maintain  their  original  unique  IDs  as  registered  with  the  SP. 

c.  Criterion  #3 

The  strength  of  the  Centralized  Model  lies  in  there  being  a  single  AO.  The 
requirement  that  users  and  SPs  have  a  choice  in  their  AOs  violates  this  characteristic  of 
the  centralized  model.  The  Federated  Model  organically  supports  the  use  of  different 
AOs  and  is,  hence,  well  suited  to  fulfill  this  requirement. 
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From  criterion  1  the  laek  of  any  need  for  eross-authentication  puts  the 
Centralized  Model  at  an  advantage  over  the  Federated  Model.  From  eriterion  2,  the 
inherent  support  of  existing  authentieation  proeesses  gives  the  Federated  Model  the 
advantage.  From  eriterion  3,  the  Centralized  Model’s  inability  to  support  multiple  AOs, 
however,  results  in  the  Federated  Model  being  the  logieal  choiee  as  the  basis  for  the 
development  of  the  use  ease.  The  Australian,  Canadian,  and  New  Zealand  governments’ 
ehoiee  of  the  Federated  Model  also  lends  weight  to  its  seleetion  [11],  [14].  However,  the 
SSO  eharaeteristie  of  the  Federated  Model  may  be  eonsidered  exeessive  for  the  proposed 
NAF.  There  is  no  explieit  requirement  for  an  SSO  funetionality  aeross  domains,  i.e., 
between  that  of  the  government  and  the  private  seetor.  Neither  are  there  explieit 
restrietions  on  implementations  that  allow  this  funetionality.  Rather,  it  is  the  envisaged 
usage  of  the  system  by  the  government,  as  a  means  of  imposing  a  second  authentication 
factor  to  that  of  the  single-faetor  system  already  in  plaee,  that  predisposes  any  upeoming 
system  toward  that  configuration,  i.e.,  any  user  who  is  logged  onto  a  non-governmental 
SP,  and  who  would  subsequently  wish  to  use  a  government  service,  would  not  be  able  to 
use  any  inherent  SSO  functionality  because  the  government  serviee  would  require  the 
entry  of  the  first  authentication  factor  that  is  separate  from  that  already  provided  to  the 
non-governmental  SP.  This  eonfiguration,  using  the  NAF  as  the  seeond  authentieation 
faetor,  is  also  in  syne  with  the  PIN-based  single  authentieation  faetor  system  employed 
by  loeal  finaneial  institutions.  This  system  utilizes  the  same  PIN  both  for  ATM 
transaetions  and  as  a  password  to  the  user  ID.  This  meehanism  demands  that  the  PIN 
remain  under  the  eontrol  of  the  issuing  organization,  the  SP,  for  privaey  and  seeurity 
reasons.  Any  allowanee  for  SSO  among  private  and  publie  entities  is  expeeted  to  require 
a  level  of  agreement  between  all  parties.  That  agreement  is  expeeted  to  require  much 
more  work  than  existing  agreements  among  eolleetions  of  educational  institutions — 
currently,  the  most  prolifie  users  of  SSO.  That  said,  within  the  government,  aecess  to 
serviees  provided  by  different  ageneies  is  expeeted  to  benefit  from  SSO;  it  is  only  at  the 
publie— private  boundary  that  no  eompromise  seems  possible  in  the  short  run. 
Nevertheless,  it  would  be  shortsighted  to  put  in  plaee  a  system  that  does  not  have  the 
potential  for  SSO,  should  the  neeessary  agreements  eome  into  effeet  in  the  future. 
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5,  Interoperable  Model 


It  would  be  more  aceurate  to  define  a  modified  Federated  Model  with  a  focus  on 
interoperability  at  the  AO  level  as  the  basis  for  the  use  case.  This  model,  to  be  termed  the 
Interoperable  Model,  inherits  all  of  the  characteristics  of  the  Federated  Model,  less  the 
SSO  characteristic.  The  Interoperable  Model,  denoted  by  placing  a  superscript  I  to  AO  to 
indicate  interoperability  among  the  AOs,  is  captured  in  Figure  2. 


INTEROPERABLE 


Figure  2.  Interoperable  Functional  Implementation  Model 


E.  USE  CASE  MODEL 

Based  upon  the  Interoperable  Model,  a  baseline  use  case  model  is  developed  to 
illustrate  the  authentication  process.  The  use  case,  in  which  both  user  and  SP  share  a 
common  AO,  is  reminiscent  of  the  Centralized  Model  and  is  considered  trivial.  The  use 
case  developed  will  be  based  on  the  condition  whereby  user  and  SP  subscribe  to  different 
AOs  for  the  provision  of  authentication  services.  The  differentiation  of  AOs  is  as  follows. 


13 


1.  AO(USER) 


Defined  as  the  AO  to  whieh  the  user  is  subseribed,  the  AO(USER)  is  responsible 
for  eredential  issuance  and  management  for  the  user;  synonymous  with  the  AO  (Issuing) 
term  used  in  the  CFC. 

2.  AO(SP) 


Defined  as  the  AO  that  the  SP  has  selected  for  the  provision  of  credential 
verification  services;  AO(SP)  is  synonymous  with  the  AO(Front)  term  used  in  the  CFC. 


Figure  3.  Authentication  Use  Case 


The  authentication  use  case  takes  places  in  the  following  steps,  as  depicted  in 
Figure  3; 

1 .  Credential  is  issued  to  subscribed  user. 

2.  Pre-registered  user  (enrolled)  presents  first  factor  to  SP  for  authentication. 

3.  SP  directs  user  to  AO(SP)  for  second  factor  authentication. 


14 


4.  AO(SP)  directs  user  to  AO(User)  for  presentation  of  second  factor. 

5.  AO(User)  verifies  presented  second  factor;  issues  assertion  to  AO(SP). 

6.  AO(SP)  transmits  assertion  to  SP,  verifying  identity  of  user. 

F.  SUMMARY 

In  this  chapter,  a  baseline  use  case  model,  detailing  the  interactions  between  the 
various  actors  as  part  of  the  authentication  process,  has  been  developed  that  will  serve  as 
a  reference  for  the  technical  implementation  model.  The  technical  implementation  model 
will  be  developed  in  later  chapters  of  this  thesis. 
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III.  AUTHENTICATION  TOKENS 


A,  OVERVIEW 

In  Chapter  II,  we  touched  on  how  a  token  would  be  used  as  part  of  the 
authentication  process.  As  previously  mentioned,  a  token  is  either  “something  you  have,” 
“something  you  know,”  or  “something  you  are”  that  can  be  used  to  positively  identify  the 
user.  This  being  the  case,  the  choice  of  the  kind  of  token  is  cardinal  to  the  implementation 
of  any  authentication  system.  Each  token  possesses  a  distinct  set  of  characteristics  that 
will  render  its  use  advantageous  under  certain  conditions  and  yet  still  susceptible  to 
certain  threats.  In  this  chapter,  the  different  types  of  tokens  and  their  characteristics  will 
be  presented,  with  particular  interest  paid  to  the  kind  of  threats  to  which  each  token  type 
is  susceptible.  The  chapter  will  continue  with  a  survey  of  the  current  form  factors  that 
implement/store  tokens.  This  chapter  will  conclude  with  a  recommendation  on  the  form 
factor  and  token  that  would  best  support  the  requirements  of  the  NAF. 

B,  TOKEN  TYPES 

A  survey  of  literature  providing  guidelines  for  the  implementation  of  an 
authentication  system  yielded  varied  classifications  for  the  types  of  tokens.  Factor-based 
lists  [14]  classify  tokens  in  accordance  with  the  underlying  factor  type.  While  simple  and 
elegant,  there  is  no  clear  distinction  among  the  variety  of  tokens  within  a  single  factor. 
Functional-type  lists  [10],  [15]  often  combine  a  token  type  and  a  form  factor,  obfuscating 
the  relationship  of  the  two  while  resulting  in  a  lengthy  catalogue.  The  list  of  token  types 
presented  below,  borrowing  heavily  from  the  NIST  SP  800-63  [10],  provides  a  succinct 
and  comprehensive  listing  of  the  current  token  types,  exclusive  of  the  form  factor  which 
will  be  used  to  implement  the  token.  Arranged  loosely  in  order  of  factor  type  are  the 
“something  you  know”  Memorized  Secret  Token  and  Pre -Registered  Knowledge  Token; 
“something  you  have”  Fook-up  Secret  Token,  Out  of  Band  Token,  One-time  Password 
Token,  and  Cryptographic  Token;  and  “something  you  are”  Biometric  Token.  The  final 
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token,  while  not  strietly  a  token  type,  eombines  different  factors  into  a  Hybrid  Token. 
The  definitions  of  each  token  type  are  as  follows. 

1.  Memorized  Secret  Token 

This  token  type  is  a  shared  secret  between  the  user  and  the  verifier  that  the  user 
memorizes,  e.g.,  a  password. 

2.  Pre-registered  Knowledge  Token 

The  Pre-registered  Knowledge  Token  is  a  set  of  prompts/responses  that  has  been 
established  between  the  user  and  the  verifier.  The  user  responds  with  the  appropriate 
answer  to  a  prompt  from  the  verifier,  e.g.,  a  response  of  “Lee”  to  the  question,  “What  is 
your  mother’s  maiden  name?” 

3.  Look-up  Secret  Token 

A  database  of  one  or  more  shared  secrets  between  the  user  and  the  verifier  is 
defined  as  a  Look-up  Secret  Token.  The  user  responds  with  the  appropriate  secret  to  a 
prompt  from  the  verifier,  e.g.,  a  code  book. 

4.  Out  of  Band  Token 

An  Out  of  Band  Token  is  a  secret  sent  from  the  verifier  to  the  user  through  a  pre- 
established  secondary  communications  medium;  the  user  subsequently  submits  that  secret 
into  the  primary  channel  for  authentication,  e.g.,  the  transmission  of  a  PIN  to  a  user’s  cell 
phone  through  SMS,  which  the  user  subsequently  enters  into  the  appropriate  field  on  the 
verifier’s  Web  site. 

5.  One-time  Password 

This  token  type  is  a  time-limited  password  obtained  from  a  device  the  user 
possesses,  hence  the  term  “one-time,”  e.g.,  a  PIN  generated  by  a  key  fob,  which  is 
subsequently  entered  into  the  appropriate  field  on  the  verifier’s  Web  site.  Authentication 
is  achieved  when  the  entered  PIN  is  the  same  as  that  generated  at  the  verifier’s  end. 
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6,  Cryptographic  Token 


A  persistent  symmetrie  or  asymmetrie  eryptographic  key  stored  in  or  generated  by 
either  hardware  or  software  means  is  a  Cryptographic  Token.  For  example,  the 
cryptographic  key  is  used  to  encrypt  a  challenge  issued  by  the  verifier  and  thereafter 
submitted  back  as  a  response.  The  verifier  decrypts  the  response  to  obtain  the  originally 
issued  challenge  and,  if  it  matches  what  was  previously  issued,  effectively  authenticates 
the  user  since  only  the  user  would  have  the  correct  key  to  encrypt  the  challenge. 

7.  Biometric  Token 

This  token  type  is  a  distinguishing  physiological  or  behavioral  characteristic 
presented  for  verification  against  a  database,  e.g.,  a  thumb-print  image  captured  on  a 
reader. 


8.  Hybrid 

A  combination  of  two  or  more  token  types  used  for  authentication  would  be 
considered  by  the  author  as  a  Hybrid  token.  While  not  strictly  a  token  type,  hybrid  tokens 
consist  of  multiple  tokens,  often  with  differing  factor  types,  yielding  what  is  known  as  a 
multi-factor  token,  e.g.,  the  use  of  a  biometric  token  to  unlock  a  smart  card  containing  the 
user’s  unique  private  cryptographic  key. 

C.  TOKEN  THREAT  ASSESSMENT 

The  strength  of  a  token  and  its  use  as  part  of  an  authentication  system  is  very 
much  dependent  upon  its  resilience  in  the  face  of  current  threats.  Each  token  type  is 
characterized  by  strengths  and  weaknesses,  which  must  be  assessed  for  suitability  of  each 
for  use  in  the  NAF.  Table  1,  based  upon  a  list  similar  to  the  one  found  in  the  NIST  SP 
800-63  standard,  lists  the  most  current  threats  to  authentication  tokens.  Appended  to  each 
threat  are  the  token  types  that  are  most  susceptible  to  that  threat.  Hybrid  tokens  are  not 
included  in  the  list.  The  following  discussion  looks  at  each  token  factor  type  in  turn. 
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Table  1.  Threats  to  Authentieation  Token  Types.  After  [10] 


Threat 

Descriotion 

Example 

Susceptible 

Token 

Theft 

A  token  with  a  physical 
manifestation  is  stolen  by  an 
Attacker. 

Hardware  cryptographic  device 
stolen;  cell  phone  stolen;  OTP  device 
stolen. 

3,4, 5, 6 

Duplication 

The  user's  token  has  been  copied 
with  or  without  his  or  her 
knowledge. 

Password  written  on  paper  disclosed; 
passwords  stored  in  electronic  file 
copied. 

Eaves¬ 

dropping 

The  token  secret  or  authenticator  is 

revealed  to  the  Attacker  as  the 
Subscriber  is  submittingthe  token  to 
send  over  the  network. 

Shoulder  surfing  of  passwords; 
keystroke  logging  on  keyboard;  PIN 
captured  from  PIN  pad  device; 
fingerprint  data  captured  from 
reader. 

1,2,3,4,5,7 

Emissions 

analysis 

The  token  is  exposed  using 
analytical  methods  outside  the 
authentication  mechanism. 

Differential  power  analysis  on  stolen 
hardware  cryptographic  token. 

4,5,6,7 

Phishing  or 
pharming 

The  token  secret  or  authenticator  is 
captured  by  fooling  the  Subscriber 
into  thinking  the  Attacker  is  a 

Verifier  or  Relying  Party. 

Password  revealed  by  Subscriber  to 
website  impersonating  as  the 

Verifier. 

1,2,3,5 

Social 

engineering 

The  Attacker  establishes  a  level  of 

trust  with  a  Subscriber  in  orderto 

convince  the  Subscriber  to  reveal  his 

or  her  token  or  token  secret. 

Token  revealed  by  Subscriver  in 
telephone  inquiry  from 
masquerading  system  administrator. 

Guessing  / 
Brute-Force 

Attack 

The  Attacker  attempts  to  obtain  the 
token  by  systematically  trying  a  large 
number  of  permutations  of  the  key 

set. 

Online/offline  dictionary  attacks  to 
guess  passwords. 

1,2,3,4 

1.  “Something  You  Know”  Token 

“Something  you  know”  tokens  are  suseeptible  to  most  forms  of  attaeks.  Their 
inherent  suseeptibility  is  exaeerbated  by  other  eonditions:  1)  User  behavioral  weaknesses 
expose  the  token  to  soeial  engineering  attaeks.  2)  Limits  on  users’  reeolleetion  abilities 
not  only  result  in  ereation  of  passwords  of  limited  eharaeter  eomplexity  and  number  but 
also  subjeet  those  passwords  to  repeated  use  in  different  domains.  3)  Vulnerability  to 
eross-referenees  allows  the  aetual  password  or  knowledge  token  to  be  implied  or  dedueed 
from  open  souree  material;  e.g.,  a  password  based  a  user’s  birth  date  ean  be  obtained 
easily  from  the  information  on  a  user’s  FaeeBook  home  page.  The  weakness  of  this  token 
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type  was  one  of  the  main  factors  for  the  push  for  a  2FA  system,  in  which  the  second 
factor  belongs  to  one  of  the  two  remaining  token  factor  types. 

2.  “Something  You  Have”  Token 

Being  physically  manifested,  “something  you  have”  tokens  are  susceptible  to 
simple  theft.  Beyond  that,  the  vulnerabilities  of  the  token  types  within  this  category  differ 
greatly.  A  Look-up  Secret  Token  is  subject  to  most  of  the  vulnerabilities  inherent  in 
“something  you  know”-type  tokens,  though  it  does  afford  greater  protection  should  there 
be  limited  reuse  of  the  token;  limited  reuse  would  overcome  the  replay  attack 
vulnerability.  An  Out  of  Band  Token  provides  greater  protection  since  it  requires  the 
attacker  to  have  access  to  the  secondary  communications  medium  used  to  transmit  the 
token.  A  phishing  Web  site  may  not  have  the  necessary  data,  e.g.,  cell  phone  number,  to 
send  the  token  to  in  order  to  complete  the  sham  even  if  a  user  unwittingly  encounters  a 
phishing  site.  An  OTP  token  takes  this  protection  further  by  limiting  the  validity  of  the 
token  in  the  time  domain,  usually  not  more  than  30  seconds.  A  Cryptographic  Token, 
while  perpetual,  is  the  least  vulnerable  token  due  in  part  to  the  generally  concealed  nature 
of  the  token;  the  user  has  rare  access  to  the  exact  characters  of  the  token;  and  the  length 
of  the  token,  typically  many  times  longer  than  that  of  a  password  or  OTP  pass-phrase, 
makes  brute  force  attacks  infeasible. 

3.  “Something  You  Are”  Token 

The  use  of  biometrics  has  already  been  restricted  to  local  mechanisms  in  Chapter 
I.  That  said,  biometrics  may  still  be  subjected  to  attacks  even  in  this  limited  setting,  such 
as  by  the  lifting  of  an  imprint  left  on  the  reader  following  a  subscriber’s  use. 

D,  TOKEN  TYPE  SELECTION 

The  previous  section  expounded  on  the  vulnerabilities  of  the  various  token  types. 
While  vulnerability  remains  a  key  determinant  in  the  choice  of  token  type,  a  key 
characteristic  that  tokens  selected  for  the  NAF  must  possess  is  the  ability  to  support  non¬ 
repudiation. 
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Non-repudiation,  while  not  a  feature  of  a  token,  has  been  explieitly  listed  as  a 
requirement  for  the  NAF  in  support  of  eertain  government  online  services.  To  realize 
non-repudiation,  any  message  exchanged  between  the  user  and  the  SP  is  required  to  have 
in  place  a  means  of  proving  undeniably  the  authenticity  of  its  source  and  its  destination, 
i.e.,  a  sender  cannot  deny  sending  the  message,  nor  can  the  receiver  deny  having  received 
the  message.  This  requirement  influences  the  choice  of  token  type  because  only  certain 
tokens  and  their  associated  mechanisms  satisfy  the  conditions  necessary  for  non¬ 
repudiation.  Chief  among  these  conditions  would  be  that  the  element  associating  an  actor 
to  a  message  be  irrevocably  unique  at  the  time  of  the  transaction.  This  condition 
effectively  eliminates  all  schemes  that  are  based  on  token  types  whereby  a  user 
demonstrates  knowledge  or  possession  of  a  secret  shared  with  the  verifier.  If  this  secret  is 
leveraged  as  a  means  toward  non-repudiation — e.g.,  by  attaching  an  encrypted  digest  of 
the  message  to  an  outgoing  e-mail  as  a  form  of  a  digital  signature  using  a  shared 
symmetric  key — there  is  a  chance  that  either  the  user  or  verifier  may  falsely  claim  that  a 
message  originated  from  the  other  party  instead  of  themselves,  since  both  the  user  and  the 
verifier  have  equal  access  to  the  same  symmetric  encryption  key  and,  hence,  are  both  able 
to  form  the  digital  signature.  Hybrid  schemes  that  generate  a  “signature”  based  upon  a 
combination  of  transaction  attributes  is  still  subject  to  replication  by  an  entity,  usually  the 
verifier,  with  knowledge  of  the  component  attributes  of  the  signature  [16].  This  leaves 
asymmetric  cryptographic  schemes  as  the  only  reasonable  choice  for  solutions  that 
require  non-repudiation.  The  private  key,  which  only  the  user  possesses  and  uses  to 
digitally  sign  any  outgoing  messages,  may  be  irrevocably  traced  back  to  the  user  should 
the  need  arise,  assuming  a  robust  Public  Key  Infrastructure  (PKI)  is  in  place.  Security  is 
further  enhanced  if  cryptographic  operations  that  generate  the  digital  signature  are 
performed  by  a  hardware  device  unique  to  the  user,  as  compared  to  software  variants, 
which  are  subject  to  risks  inherent  particularly  to  software  design.  The  generation  of 
digital  signatures  with  the  use  of  an  asymmetric  key  is  discussed  in  detail  in  the  next 
chapter. 

From  the  previous  discussion  on  authentication  threats,  it  is  clear  that 
Cryptographic  Tokens  would  provide  the  best  protection  against  most  current  threats. 
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When  the  need  for  non-repudiation  is  faetored  in,  the  only  ehoiee  would  be  an 
Asymmetrie  Key  Cryptographie  Token.  That  said,  users  may  still  ehoose  to  leverage  on 
token  types  that  do  not  support  non-repudiation  for  authentieation  to  SPs  that  do  not 
require  it.  This  is  espeeially  pertinent  in  view  of  the  relatively  larger  infrastrueture 
footprint  required  of  the  user  to  support  non-repudiation,  with  a  direet  impaet  on 
mobility.  For  this  subset  of  transaetions,  the  remaining  token  types  that  are  of  the 
“something  the  user  has”  form  may  be  utilized  as  the  seeond  authentieation  faetor, 
partieularly  OTP  and  Out  of  Band  Tokens. 

E,  FORM  FACTOR  TYPES  AND  SELECTION 

A  survey  of  various  authentieation  operators  yielded  a  large  variety  of 
authentieation  form  faetors.  A  majority  of  solutions  that  elaim  to  apply  strong 
authentieation  prineiples  implement  a  variation  of  an  OTP  meehanism  [17],  e.g.,  RSA 
Seeure-ID,  VASCO  Digipass,  Aladdin  eToken.  The  major  advantage  afforded  by  this 
form  of  authentieation  is  its  eonneetionless  nature.  Unfortunately,  this  method  does  not 
ensure  non-repudiation  beeause  both  the  user  and  verifier  would  possess  the  same  OTP. 
Continuing  from  the  previous  diseussion,  only  hardware-based,  asymmetrie  key 
eryptography-supporting  solutions  would  be  suffieiently  strong  to  withstand  eurrent 
threats  and  yet  meet  the  requirements  for  non-repudiation.  Market  trends  also  show  a 
steady  inerease  in  the  aeeeptanee  of  PKI-based  smart  eard  solutions.  This  ehapter 
diseusses  various  form  faetors  that  implement  OTP,  Out  of  Band,  and  Asymmetrie  Key 
Cryptographie  Tokens. 

1,  Contact  Multiprocessor  Smart  Card 

A  smart  card  is  “a  credit-card  sized  card  with  an  embedded  processor  and 
memory  that  can  receive  input,  process  it,  and  provide  output”  [18].  It  operates  by 
performing  cryptographic  operations  on  inbound  data  with  the  user’s  private  key  and  then 
outputs  the  encrypted  message  back  to  its  source.  The  smart  card  has  been  in  use  by 
major  institutions,  including  the  U.S.  Department  of  Defense.  The  cost  of  a  basic  smart- 
card  solution  is  US$23  per  individual  (smart  card  US$3 [19],  smart  card  reader 
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US$20[20]).  The  smart  card  form  factor  is  also  familiar  to  users  since  all  would  already 
be  in  possession  of  a  government-issued  ID  card.  It  is  not  too  remote  to  expect  such  an  ID 
card  to  be  upgraded  to  smart  card  specifications  as  a  means  toward  nationwide 
implementation.  Yet,  while  a  smart  card  solution  is  fairly  cost  competitive,  the 
requirement  for  an  additional  reader  may  render  the  solution  less  attractive  in  light  of  the 
current  trends  towards  portability. 

2,  USB  Token 

A  USB  token  is  essentially  a  key  fob  containing  a  built-in  USB  port  with  the  same 
processing  functionality  as  a  smart  card.  This  form  factor  was  designed  with  the  aim  of 
eliminating  the  need  for  a  separate  smart  card  reader.  Users  need  only  attach  the  key  fob 
to  any  available  USB  port  for  authentication  to  be  effectively  carried  out.  The  security  of 
this  form  factor  is  strengthened  through  adherence  to  the  FIPS  140-2  standard, 
safeguarding  the  cryptographic  keys  held  within  through  tamper  proofing  and  associated 
methods.  This  form  factor  is  also  congruent  with  the  OTP  key  fob,  which  is  currently 
issued  by  most  major  banking  institutions  as  their  means  of  strong  authentication,  in 
terms  of  look  and  feel  and,  hence,  would  be  most  familiar  to  users  of  online  banking.  The 
price  per  unit  is  expected  to  be  less  than  US$30  per  unit  [21].  The  USB  token  can  be 
further  enhanced  with  the  additional  requirement  of  the  need  for  a  second  token,  usually 
biometric  or  PIN-based,  to  unlock  the  cryptographic  keys  stored  within.  This  addition  of 
a  token  will  require  an  enhancement  to  the  standard  smart  card/key  fob  form  factor, 
usually  through  the  addition  of  a  key  pad  or  a  biometric  scanner.  This  enhancement  is 
also  available  to  the  smart  card  form  factor. 

3,  Contactless  Hardware  Device 

The  USB  token,  while  not  requiring  a  separate  reader,  still  requires  direct 
connection  via  a  USB  port.  The  advent  of  Personal  Area  Network  (PAN)  technologies, 
such  as  Bluetooth  and  RFID,  makes  wireless  connectivity  possible.  Consumer  devices 
such  as  smartphones  can  be  leveraged  as  a  means  of  storing  the  necessary  keys  and 
performing  the  desired  cryptographic  operations.  The  smartphone  can  also  be  utilized  to 
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implement  Out  of  Band  token-based  solutions,  partieularly  by  the  entering  of  an  OTP 
token,  reeeived  via  SMS  from  the  AO,  into  the  AO’s  authentieation  page  by  the  user. 
Another  use  of  the  smartphone  implements  biometries  in  the  form  of  voiee  authentieation 
as  a  third  authentieation  faetor  whereby  a  user  receives  a  call  on  his  phone  (second  out- 
of-band  token)  and  he  is  asked  to  read  out  his  PIN.  The  system  authenticates  the  user 
based  on  the  unique  characteristics  of  his  voice  [22].  Most  smartphones  enable 
connectivity  via  Bluetooth,  though  the  smartphone  may  require  the  installation  of  an 
additional  trusted  cryptographic  module. 

Another  contactless  hardware  device  is  a  contactless  smart  card.  As  the  name 
suggests,  it  has  essentially  the  same  functionality  as  a  smart  card  but  with  an  add-on 
wireless  means  of  connectivity — radio  frequency.  The  performance  characteristics  of  the 
contactless  smart  are  specified  by  the  ISO/IEC  144443  standard;  among  other  features,  it 
defines  the  communications  distance  at  10  cm.  Large-scale  implementations  include  the 
Octopus  Card  in  Hong  Kong  and  the  Ezylink  card  in  Singapore.  While  the  cost  of  a 
contactless  smart  card  is  competitive,  the  lack  of  a  reader  in  most  consumer  products 
means  this  form  factor  may  require  significant  investment  to  implement.  The  cost  of  a 
contactless  reader  is  expected  to  be  around  US$90.00. 

The  key  issue  regarding  the  use  of  contactless  solutions  is  security.  Wireless 
communications  means  are  associated  with  numerous  security  concerns.  The  complexity 
of  smartphones,  their  dual-use  nature  for  non-secured  communications,  and  the  relative 
lack  of  security  inherent  in  smartphone  operating  systems  [23]  increase  the  chances  of 
subversion  and  subsequent  compromise  of  the  embedded  cryptographic  keys. 

4,  Key-fob 

A  key-fob  is  a  device  similar  in  look  and  feel  to  a  key-chain  ornament  but 
containing  electronics  capable  of  issuing  a  unique  OTP  upon  activation,  visible  to  the 
user  through  a  liquid  crystal  display.  Such  systems  place  no  additional  demands  on  users, 
such  as  needing  to  use  and/or  install  hardware  and  software,  except  for  the  need  to  have 
the  key-fob  in  their  possession.  It  is  easily  revoked  from  the  AO  end  and  can  be  easily 
replaced.  The  key  fob  also  benefits  from  being  the  dominant  form  factor  in  current  use. 
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Each  key  fob  costs  about  US$5.00  [24].Variants  of  a  key  fob  include  the  addition  of  a 
keypad  so  that  the  user  may  enter  a  PIN  to  unlock  the  generated  OTP.  Such  a  mechanism 
is  similar  to  the  enhanced  smart  card  previously  mentioned. 

With  each  form  factor  having  its  own  strengths  and  weaknesses,  and  in  line  with 
the  government’s  aim  of  providing  for  choice,  it  may  be  best  if  the  decision  of  which 
form  factor  to  adopt  be  left  to  the  consumer,  based  on  his  or  her  own  lifestyle.  Each  form 
factor  possesses  distinct  characteristics  in  terms  of  footprint,  infrastructure  investment, 
and  security  concerns.  A  caveat  is  that  the  selected  form  factor  must  be  able  to  implement 
the  correct  token  type  for  the  requested  service. 

F.  SUMMARY 

In  this  chapter,  a  summary  of  the  various  token  types  in  regards  to  current  threats 
has  been  presented.  An  asymmetric  cryptography-capable  token  has  been  selected  as  the 
best  means  for  authentication  while  ensuring  non-repudiation,  whereas  an  OTP  or  Out  of 
Band  token-based  system  would  suffice  for  systems  that  do  not  require  non-repudiation. 
In  the  next  chapter,  we  will  look  at  the  identity  frameworks  that  will  be  leveraged  on  to 
authenticate  the  user  to  the  SP. 
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IV.  IDENTITY  FRAMEWORKS 


A,  OVERVIEW 

In  Chapter  II,  a  use  ease  was  developed  as  a  baseline  referenee  for  the 
implementation  of  the  National  Authentieation  Framework  (NAF).  Key  eomponents  of 
the  proeess  are  those  of  authentieation  and  the  transmission  of  the  assertion  from  the 
Authentieation  Operator  (AO)  to  the  Serviee  Provider  (SP),  indieating  eoneurrenee  as  to 
the  identity  of  the  user.  While  authentieation  in  itself  is  a  fairly  well-developed 
meehanism,  it  is  the  transmission  of  the  assertion  that  poses  a  ehallenge  in  the 
implementation  of  the  authentieation  framework.  The  possible  involvement  of  more  than 
a  single  AO  is  an  issue  that  has  yet  to  be  addressed  speeifieally  [25].  The  realization  of 
both  an  authentieation  and  an  assertion  transmission  is  dependent  upon  the  ehoiee  of  the 
supporting  identity  framework.  The  underlying  protoeols  and  standards  that  make  up 
eaeh  framework  vary  in  their  support  of  the  seleeted  token  type  and  assoeiated 
authentieation  meehanisms.  The  key  differentiating  faetor  lies  in  whether  a  framework  is 
Non-repudiation  Supporting  (NRS)  or  Non-repudiation  Non-supporting  (NRNS).  It  has 
been  established  in  Chapter  III  that  both  forms  will  eo-exist  as  part  of  the  overall  NAF. 
This  ehapter  will  explore  eurrent  frameworks  that  support  either  of  the  two  forms, 
evaluate  their  respeetive  suitabilities,  and  draw  a  eonelusion  about  the  best-fit  framework 
for  support  of  the  NAF. 

B,  IDENTITY  FRAMEWORK  (NON-REPUDIATION  SUPPORTING) 

1.  Overview 

The  use  of  asymmetrie  key  eryptography  for  authentieation  is  supported  by  a 
eolleetion  of  entities  known  as  Publie  Key  Infrastrueture  (PKI).  These  entities  provide  the 
means,  not  just  for  authentieation,  but  also  for  ensuring  non-repudiation,  one  of  the  key 
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requirements  of  the  NAF.  This  seetion  will  begin  with  an  overview  as  to  how  asymmetrie 
key  eryptography  operates,  will  provide  a  list  of  eritieal  supporting  standards,  and  will 
eonelude  with  a  deseription  of  how  these  standards  are  leveraged  to  enable  NRS. 

2.  Asymmetric  Key  Cryptography 

In  Asymmetrie  Key  Cryptography  (AKC),  as  the  name  suggests,  different  keys 
are  used  to  enerypt  and  deerypt  the  data  of  interest.  Supporting  algorithms  that  offer  AKC 
inelude  the  Rivest- Shamir- Adleman  algorithm  and  the  elliptie  eurve  algorithm.  While 
eaeh  algorithm  differs  in  the  means  of  key  generation,  the  meehanism  in  whieh  the  key- 
pairs  are  utilized  remains  the  same  and  will  be  diseussed  in  this  seetion.  The  use  of  AKC 
for  authentieation  and  generating  digital  signatures  is  also  diseussed. 

a.  Encryption  and  Decryption 

The  meehanism  for  employing  eneryption  and  deeryption  with  AKC  is  as 
follows:  Eaeh  user  has  a  key-pair,  eonsisting  of  a  publie  key  and  a  private  key.  The  publie 
key  is  freely  available,  while  the  private  key  is  kept  only  by  the  user.  Assume  that  user  A, 
Aliee,  wishes  to  send  a  message  M  to  user  B,  Bob.  Aliee  wishes  to  ensure  that  no  person 
other  than  Bob  will  be  able  to  read  the  message.  Upon  generation  of  the  message  M, 
Aliee  uses  Bob’s  publie  key,  KB,  to  enerypt  the  message,  resulting  in  Mkb-  Bob,  upon 
reeeipt  of  Mkb,  uses  his  personal  private  key,  KB'\  to  deerypt  Mkb  and  sueeessfully 
obtains  the  message.  Beeause  only  Bob  possesses  the  requisite  private  key,  only  Bob  ean 
deerypt  the  message;  and  no  one  else,  not  even  Aliee,  who  used  Bob’s  publie  key  to 
enerypt  the  message,  is  able  to  retrieve  the  message  from  its  enerypted  form.  Bob’s 
publie  key  is  publiely  available  in  the  form  of  a  digital  eertifieate,  the  strueture  of  whieh 
will  be  eovered  shortly.  In  effeet,  eaeh  person  would  have  a  private  key,  and  a  publie  key, 
together  termed  a  publie-private  key-pair. 
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b.  Authentication 

Using  AKC  for  authentication  usually  features  a  challenge-response 
protocol.  The  process  is  illustrated  in  Figure  4. 


BOB 


Challenge  C 


Encrypt  C  >  Ckb'"' 

<- 

Response  Ckb'"' 


Decrypt  Ckb'^  >  C 


Bob  Authenticated 


Figure  4.  Authentication  Process 


Bob  wishes  to  assess  a  resource  controlled  by  Alice.  Alice  issues  a 
challenge  C  to  Bob.  Bob  uses  his  private  key  KB‘'  to  encrypt  the  challenge  Ckb’^  and 
sends  the  encrypted  challenge,  now  termed  a  response,  back  to  Alice.  Alice  utilizes  Bob’s 
public  key  to  decrypt  the  response.  If  Bob’s  identity  (as  provided  by  Bob’s  identity  being 
“bound”  to  the  public  key  used  by  Alice)  is  authentic,  the  response  will  decrypt 
accurately  to  reveal  the  challenge.  Bob’s  identity  is  verified  because  only  he  should  have 
possession  of  the  private  key  that  corresponds  to  the  freely  available  public  key  used  to 
decrypt  the  response. 
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c. 


Digital  Signature 


A  digital  signature  is  the  primary  means  by  which  non-repudiation  is 
effected.  Essentially,  any  message  that  is  accompanied  by  a  digital  signature  can  be 
trusted  in  terms  of  its  source,  since  the  digital  signature  is  derived  from  a  sender’s  private 
key  and  the  message  itself.  The  digital  signature  generation  and  verification  process  is 
depicted  in  Figure  5. 
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Figure  5.  Digital  Signature  Generation  and  Verification 


The  structure  of  the  digital  signature  is  simple.  Bob  intends  to  send  a 
message  M  to  Alice.  After  composing  the  message.  Bob  hashes  the  message,  resulting  in 
a  hashed  message  MH,  and  subsequently  encrypts  the  hash  with  his  private  key,  resulting 
in  MHkb  This  encrypted  hash  is  sent  together  with  the  original  message  to  Alice.  A 
hash  is  the  result  of  the  performance  of  a  hashing  function,  such  as  SHA-1  or  MD5,  on 
the  message,  resulting  in  a  message  digest  that  cannot  be  “reversed”  back  to  the  original 
message  by  any  existing  means,  even  by  the  message  originator.  Alice,  upon  receipt  of 
the  message,  first  hashes  the  accompanying  message,  then  proceeds  to  use  Bob’s  public 
key  to  decrypt  the  encrypted  hashed  message  that  Bob  sent  along  with  the  original 
message.  If  the  decrypted  hashed  message  and  the  new  hash  match,  then  the  sender’s 
identity  is  established. 
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3,  Supporting  PKI  Standards 


A  suite  of  established  and  reeognized  standards  supports  the  implementation  of 
PKI.  Chief  among  the  standards  is  the  standard  that  addresses  the  format  of  the  digital 
eertifieate  and  the  protoeol  used  to  support  authentieation  via  smart  eard-type  tokens. 
These  and  other  standards  are  diseussed  in  the  rest  of  this  seetion. 

(L  X.509 

The  X.509  standard  (RFC  5280)  dehnes  one  possible  format  of  a  digital 
eertiheate.  The  digital  eertifieate  is  the  basis  for  the  authentieity  of  a  freely  available 
publie  key.  The  digital  eertifieate  is  eomposed  primarily  of  the  name  of  the  user  and  the 
AO,  the  user’s  publie  key,  the  validity  period  of  the  publie  key,  the  identifier  for  the  type 
of  eryptographie  algorithm  used,  and  the  digital  signature  of  the  AO  [26].  The  AO’s 
digital  signature  signifies  the  validity  of  the  information  provided  in  the  eertifieate, 
notably  the  binding  of  the  user’s  identity  to  the  user’s  publie  key.  X.509  also  speeifies  the 
format  of  the  Certifieate  Revoeation  List  (CRL).  The  CRL  is  a  time-stamped  list  of  ah 
eertifieates  that  have  been  revoked  and  ean  no  longer  be  relied  upon.  The  CRTs  are 
signed  by  the  issuer  and,  like  publie  keys,  are  available  publiely.  Prior  to  relianee  on  any 
publie  key  found  within  a  submitted  digital  eertifieate,  a  eheek  should  be  made  against 
the  most  reeently  published  CRL  to  ensure  that  the  eertifieate  a)  has  a  valid  AO  signature, 
b)  has  not  expired,  e)  does  not  appear  on  a  CRL,  and  d)  is  being  used  as  intended. 

b.  Transport  Layer  Security  Protocol 

The  most  widely  used  protoeol  for  seeuring  e-eommeree  transaetions  is 
the  Transport  Layer  Seeurity  Protoeol  (TLS).  Designed  to  provide  “privaey  and  data 
integrity  between  two  oommunieating  applieations”  [27],  TLS  is  widely  aeeepted  and 
well  supported.  Transaetion  seeurity  is  aehieved  first  through  eondueting  mutual 
authentieation  and  thereafter  establishing  a  seeure  ehannel  for  the  exehange  of  data. 
Current  use  of  TLS  is  restrieted  to  server  authentieation,  sinee  most  users  do  not  possess 
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the  necessary  tokens  for  user  authentication.  With  the  NAF  in  place,  users  can  be 
authenticated  to  the  SP  using  TLS  via  their  public-private  key-pairs.  The  authentication 


mechanism  is  illustrated  in  Figure  6. 
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Figure  6.  TLS  Authentication  Process 

The  user  sends  to  the  SP  a  message,  ClientHello,  indicating  the  user’s 
intention  to  establish  a  connection,  shown  in  step  one.  The  ClientHello  message  contains 
the  version  of  TLS  in  use,  a  client  random  number,  Rc,  a  list  of  applicable  cipher  suites, 
and  a  list  of  compression  methods.  The  SP  server,  upon  receipt  of  the  message,  responds 
in  kind  with  a  chain  of  messages.  The  first  message,  ServerHello,  contains  a  field 
indicating  the  TLS  version  in  use  by  the  server,  a  server  random  number,  Rs,  the  cipher 
suite  selected  by  the  server,  and  the  compression  method  selected  by  the  server, 
represented  by  the  respective  standardized  cipher  suite  and  compression  method  IDs. 
This  is  followed  by  the  X.509-formatted  server  digital  certificate.  If  the  SP  wishes  to 
authenticate  the  user,  a  CertificateRequest  message  is  appended  as  well.  This  message 
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chain  from  the  server,  as  shown  in  step  two,  is  eoncluded  with  the  message 
ServerHelloDone.  The  user,  upon  detection  of  ServerHelloDone,  proceeds  to  transmit  its 
own  message  chain  to  the  SP,  commencing  with  the  user’s  X.509-formatted  digital 
certificate.  The  seeond  message  in  the  chain  is  a  server  publie  key— encrypted  user¬ 
generated  48-byte  pseudorandom  number  premaster  seeret,  S.  This  is  followed  by  a 
CertificateVerijy  message,  which  is  a  user  digitally  signed  hash  of  all  previous  messages 
used  in  the  handshaking  process.  The  final  message  in  the  chain,  the  Finished  message,  is 
substantially  different  from  the  other  messages  in  the  chain:  its  contents  are  the  enerypted 
hash  of  all  previous  messages  utilizing  a  symmetric  key,  K,  derived  from  the  48-byte 
pseudorandom  number,  S,  the  client  random  number,  Rc,  and  the  server  random 
number,  Rs;  hence,  K=f(S,Rc,Rs).  The  user-message  chain  is  shown  in  step  three.  The 
server  likewise  responds  to  the  user  with  its  own  Finished  message,  a  hashed  message 
digest  of  all  previous  transacted  messages  also  encrypted  with  K.  Note  that  key  K,  known 
only  to  the  user  and  the  SP,  will  be  used  to  encrypt  and  decrypt  all  further 
communications  between  the  two,  ensuring  confidentiality.  Mutual  authentication  is 
assured  in  a  few  ways.  Firstly,  the  48-byte  pseudorandom  number  S  used  to  generate  the 
key  K  was  encrypted  with  the  AO-eertified  SP  server’s  publie  key.  The  SP  server  will 
only  be  able  to  generate  the  correct  K  if  it  possesses  the  corresponding  private  key  which 
allows  the  server  to  decrypt  and  obtain  the  48-byte  pseudorandom  seed  number  S.  The 
user  is  likewise  authentieated  by  the  server  through  verification  of  the  digital  signature 
submitted  as  part  of  the  CerificateVerify  message.  The  accurate  exchange  of  the  Finished 
messages  is  proof  that  both  the  user  and  the  server  have  derived  the  correct  K  from  the 
list  of  transaetions.  If  at  any  time  any  of  the  transmissions  in  the  proeess  should  fail,  the 
connection  is  immediately  terminated. 

4.  Infrastructure 

The  implementation  of  PKI  is  not  just  dependent  on  the  identifieation  of  the 
correet  standards,  but  also  on  the  implementation  of  these  standards  in  a  manner  that 
ensures  seeurity.  Examples  of  sub-par  implementations  of  otherwise  trustworthy 
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standards  include  WEPs  implementation  of  RC4.  In  PKI,  two  key  funetions  have  been 
identified,  certificate  issuance  and  certificate  revocation. 

a.  Certificate  Issuance 

The  issuanee  of  eertifieates  to  both  users  and  SPs  (eolleetively  termed 
client  heneeforth  in  this  seetion,  both  being  elients  to  the  AO)  alike  is  key  to  the 
implementation  of  PKI.  It  is  the  trust  that  both  parties  plaee  in  the  AO  having  eorreetly 
exeeuted  the  neeessary  identity  baekground  eheeks  prior  to  issuanee  of  a  eertifieate  that  is 
the  basis  of  PKI.  In  this  regard,  the  AO  may  play  the  role  of  the  Certifieation  Authority 
(CA),  or  the  Registration  Authority  (RA),  or  both.  The  latter  is  responsible  for  the 
generation  of  the  asymmetrie  key-pair,  maintenanee  of  the  validity  of  the  key-pair,  and 
issuing  the  key-pair  to  the  dependent  elient,  while  the  former  ereates  the  eorresponding 
digital  eertifieate.  For  a  elient  to  reeeive  eertifioation,  the  elient  must  positively  prove  his 
identity,  often  in  person  to  the  RA.  Due  to  the  importanee  of  the  CA,  the  operations  of  a 
CA  are  often  governed  by  legislation  [28]. 

b.  Key  Recovery 

Onee  a  elient’ s  publie-private  key-pair  is  in  use,  the  elient  may  faee  issues 
of  having  misplaeed  the  private  key.  In  sueh  situations,  there  is  a  need  to  have  in  plaee 
meehanisms  for  key  baek-up  and/or  reeovery.  This  responsibility  remains  with  the 
CA/RA;  a  mutual  agreement  with  the  elient  about  the  proper  proeedures  to  follow  in  sueh 
an  event  should  be  established  during  issuanee.  The  notion  of  a  private  key  being  kept  by 
a  seeond  party  other  than  the  elient  may  prove  to  be  the  undoing  of  the  reliability  of  the 
said  key  for  non-repudiation.  A  work-around  involves  eaeh  elient  having  two  sets  of  key- 
pairs:  one  set  for  eonfidentiality,  i.e.,  eneryption/deeryption  of  data  purposes;  and  one  set 
for  integrity,  i.e.,  digital  signature  purposes.  The  private  key  used  for  deeryption  of  data 
may  then  be  kept  by  a  trusted  third  party. 
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c.  Certificate  Revocation 

While  the  validity  of  a  certifieate  is  cheeked  during  an  authentication 
transaction,  there  may  be  events  that  lead  to  the  premature  invalidation  of  a  public  key, 
rendering  a  digital  certificate  void.  Beyond  natural  expiration  of  a  key  and  the  need  for 
regeneration,  there  is  also  a  requirement  that  a  mechanism  be  in  place  that  ensures  that 
the  relying  party  in  a  transaction  be  able  to  retrieve  data  stating  that  the  said  public  key 
has  not  been  invalidated  prematurely.  This  check  on  invalidation  is  made  through 
comparison  against  a  CRL,  generally  maintained  by  the  issuing  CA.  Should  a  certificate 
be  found  to  be  on  a  CRL,  dependence  on  the  certificate  is  immediately  suspect.  Proper 
distribution  infrastructure  must  be  put  in  place  for  the  proper  dissemination  of  the  CRLs 
to  the  relying  parties.  Protocols  that  support  revocation  include  the  Online  Certificate 
Status  Protocol,  and  the  Simple  Certificate  Validation  Protocol  [29].  The  format  of  the 
CRL  is  defined  by  the  X.509  standard. 

C.  IDENTITY  FRAMEWORK  (NON-REPUDIATION  NON-SUPPORTING) 

1,  Overview 

The  current  state-of-the-art  in  NRNS  frameworks  can  be  divided  into  two 
opposing  camps  [30],  user-centric  and  federated.  User-centric  frameworks,  as  the  name 
suggests,  place  the  user  in  a  position  optimized  for  user  control  of  the  authentication 
process:  the  user  is  the  initiator  as  well  as  conduit  for  the  authentication  process 
information  flow.  In  this  form,  user  privacy  is  greatly  enhanced.  Implementations  that 
can  be  classified  as  user-centric  are  OpenID  and  a  collective  group  known  as  Infocard. 
Federated  frameworks  were  designed  to  provide  SSO  functionality  within  a  circle  of  pre- 
established  trust  relationships,  or  a  federation.  The  user  continues  to  play  an  active, 
though  relatively  diminished,  role  in  federated  frameworks:  interactions  between  AOs 
and  SPs  may  pass  over  the  user  in  favor  of  the  already  established  connections  between 
the  two.  The  two  leading  standards  supporting  federation  are  the  Security  Assertion 
Markup  Language  (SAML)  v2.0  and  Web  Services  Federation  (WS -Federation) 
standards.  Each  standard  is  detailed  below. 
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2,  OpenID 


The  OpenID  framework  was  developed  based  upon  the  principle  whereby  a  user 
may  authenticate  through  presentation  of  a  Web  resource  that  the  user  controls  [31]. 
Simply  put,  authentication  is  dependent  upon  the  user  proving  ownership  of  the  said 
resource  [32],  OpenID  is  an  evolving  framework  with  widespread  adoption  on  the 
Internet;  notable  AOs  include  those  of  Google  and  Yahoo,  with  Facebook  and  MySpace 
as  implementers.  Its  popularity  stems  from  its  simplicity  of  use;  no  additional  software  or 
hardware  is  required — at  least,  not  in  its  present  form — and  there  is  no  requirement  for  a 
password.  Currently,  in  v2.0  of  its  implementation,  responsibility  for  development  of 
OpenID  is  undertaken  by  the  community-based  OpenID  Foundation.  Built  upon  OASIS 
standards  (XRI,  XRDS),  OpenID  itself  has  yet  to  achieve  widespread  peer  recognition  as 
a  standard.  However,  it  has  attained  U.S.  approval  for  use  as  an  identity  authentication 
framework  in  support  of  low-risk  transactions;  all  derived  data  from  the  authentication 
are  to  be  treated  as  unreliable  [33].  This  assurance  classification  is  due  in  part  to  the 
documented  susceptibility  of  the  framework  to  phishing  and  man-in-the-middle  attacks 
[30]. 


USER 


Figure  7.  OpenID  Authentication  Process  Flow  Diagram.  After  [32] 
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Figure  7  depicts  the  authentication  process  in  OpenID.  A  Uniform  Resource 
Locator  (URL)  address  or  Extensible  Resource  Identifier  (XRI-ID)  is  used  as  a  user’s 
identifier.  A  user  may  obtain  the  identifier  through  pre-registration  with  an  AO.  Once  at 
the  SP’s  login  portal,  the  user  presents  the  said  identifier,  shown  in  step  one.  In  step  two, 
the  SP  evokes  the  XRI  Resolution  Protocol  (XRI-Res)  to  discover  the  identity  of  the 
supporting  AO  based  on  the  submitted  identifier,  followed  by  the  establishment  of  a 
shared  secret  between  the  two,  as  shown  in  step  three.  The  user  is  then  re-directed  to  the 
AO,  as  in  step  four,  followed  by  authentication  with  the  AO,  as  in  step  five.  Note  that  this 
authentication  in  itself  can  leverage  any  of  the  token  types  previously  mentioned  in 
Chapter  11.  Once  verified,  the  user  is  redirected  back  to  the  SP  with  an  assertion  from  the 
AO,  as  in  step  six  [32]. 

3,  Infocard 

Infocard  refers  to  a  collection  of  proposed  implementations  that  are  based  on  the 
notion  of  the  submission  of  an  Information  Card  (I-card)  to  enable  authentication.  The  I- 
cards  are  stored  in  and  selected  from  a  repository  known  as  a  card  selector,  software  that 
manages  all  of  a  user’s  I-cards.  Leading  implementations  of  the  Infocard  methodology 
include  Microsoft’s  CardSpace  and  the  InCommon  framework.  To  date,  CardSpace  has 
been  included  with  recent  versions  of  Windows  [34],  while  the  InCommon  framework  is 
undergoing  reviews  for  use  for  e-government  purposes  in  the  United  States  [35]. 
CardSpace  itself  leverages  upon  the  Web  Services  (WS*)  suite  of  standards  as  its 
infrastructure,  though  CardSpace  itself  has  yet  to  be  accepted  as  an  industry  standard 
[36].  With  CardSpace  as  the  dominant  implementation  for  the  Infocard  framework,  it  will 
be  used  as  the  basis  for  the  rest  of  the  discussion. 

As  can  be  seen  in  Figure  8,  in  CardSpace,  each  time  a  user  accesses  a  service 
requiring  authentication,  the  SP  will  reply  with  a  request  for  a  security  token,  as  shown  in 
step  one.  The  user  selects  the  appropriate  security  I-card  from  the  card  selector  software 
and  presents  this  card  as  the  security  token  to  the  SP,  as  shown  in  step  two.  Two  types  of 


37 


Figure  8.  CardSpace  Authentication  Flow  Process.  After  [36] 

cards  may  be  submitted.  A  Personal  Card  is  a  self-asserted/created  card  containing  details 
that  will  facilitate  authentication,  such  as  a  user  ID  and  password  combination.  A 
Managed  Card  is  one  that  is  provided  by  an  AO;  it  typically  requires  a  secondary 
authentication  step  to  be  undertaken  between  the  AO  and  the  user,  as  shown  in  step  three, 
before  a  token  is  made  available  by  the  AO,  shown  in  step  four.  The  said  token  is 
reviewed  by  the  user  and  then  forwarded  to  the  SP,  shown  in  step  five.  If  the  token  is 
accepted  by  the  SP,  the  user  is  then  granted  access  to  the  service,  completing  the 
authentication  process. 

Because  the  card  selector  is  a  single  repository  for  all  of  a  user’s  digital  identities, 
it  is  a  prime  target  for  the  determined  attacker.  However,  it  is  also  claimed  that  the  card 
selector  may  decrease  its  susceptibility  to  phishing  through  warnings  should  the  user 
transact  with  a  new  service,  or  through  customized  tokens  that  are  only  useful  to  the  SP 
and  no  others,  thereby  preventing  a  replay  attack  [35]. 
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4,  Security  Assertion  Markup  Language 


SAML,  at  its  core,  is  not  strictly  an  authentication  framework.  It  is,  as  the  name 
suggests,  a  standard  that  dictates  how  assertions  are  to  be  formatted  for  transmission 
between  parties  in  a  form  that  is  non-proprietary.  This  can  even  be  leveraged  by  user¬ 
centric  frameworks.  Building  upon  this  base  specification,  though,  are  components  that, 
when  put  together,  define  an  eponymous  composite  standard  for  authentication.  First 
defined  in  November  2002,  the  standard  has  since  seen  a  major  revision,  emerging  as 
SAML  v2.0  in  2005.  This  new  version  incorporates  inputs  from  then-leading 
implementations  of  Federated  Identity,  including  those  of  the  Liberty  Alliance  and  the 
Intemet2  Shibboleth  project.  It  is  the  only  specification  to  have  received  recognition  as  a 
federated  identity  management  standard  by  the  Organization  for  the  Advancement  of 
Structured  Information  Standards  (OASIS). 

The  components  previously  mentioned,  as  captured  in  Figure  9,  collectively 
define  the  relationship  and  possible  interactions  between  the  user,  AO,  and  SP.  At  its  core 
is  the  assertion  component,  the  primary  construct  that  serves  to  affirm  the  identity  of  a 
user.  Each  assertion  contains  authentication,  attribute,  and  authorization  decision 
statements;  each  statement  is  composed  of  data  necessary  for  authentication  sandwiched 
between  standardized  XML  tags.  The  protocol  component  defines  the  SAML  protocols 
that  are  leveraged  upon  for  interactions  via  a  request/response  mechanism.  The  bindings 

PROFILES 

BINDINGS 

PROTOCOL 


ASSERTIONS 


Figure  9.  SAML  v2.0  Component  Affiliations.After  [37] 


39 


component  provides  the  linkage  between  SAML  protocols  and  the  underlying  non-SAML 
transport  layer  protoeols.  The  profile  component  speeifies  how  eombinations  of  assertion, 
protoeol,  and  binding  components  are  amalgamated  to  support  a  speeific  funetion.  It  is 
this  profile  eomponent  that  provides  a  tangible  expression  of  how  SAML  can  be 
leveraged  to  support  authentieation,  this  expression  differentiates  SAML  from  non- 
SAML  frameworks  that  only  use  the  base  assertion  component  in  their  specifications. 
The  Web  Browser  SSO  Profile  will  be  used  to  illustrate  SAML’s  use. 

As  is  shown  in  Figure  10  step  1,  the  user  visits  the  SP  site  to  aeeess  a  serviee.  As 
the  user  has  not  been  authentieated,  the  user  is  redirected  to  the  AO  for  authentication, 
depicted  by  step  2.  In  step  3,  the  user  authentieates  to  the  AO  through  a  pre-established 
authentieation  means.  Step  4  sees  the  AO  build  an  assertion  that  signifies  that  the  user’s 
identity  has  been  affirmed  upon  verification.  The  user  is  thereafter  direeted  back  to  the  SP 
by  the  AO  with  the  assertion  in  tow,  completing  the  authentication  process,  as  in  step  5. 


USER 


Figure  10.  SAML  Authentication  Process  Flow  Diagram 

5,  WS-Federation  Language 

WS-Federation  Language  (WS-F)  was  developed  to  provide  SSO-federated 

functionality  as  part  of  the  WS*  suite  of  speeifications.  It  defines  how  authentieation, 
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authorization,  attribute,  and  pseudonym  serviees  can  be  effected  via  reliance  on  an 
underlying  Security  Token  Service  (STS)  [38];  STS  itself  is  a  specification  of  WS-Trust, 
a  mechanism  developed  for  the  management  of  security  tokens  or  assertions.  The 
services  that  WS-F  offers  are  similar  to  those  of  SAML  but  optimized  for  a  Web-services 
environment.  The  WS*  suite  of  standards  was  developed  jointly  by  a  consortium  of 
industry  heavyweights,  including  Microsoft,  IBM,  and  BEA,  to  meet  the  challenges  of 
Internet  2.0  and  the  growing  interest  in  systems  developed  based  upon  the  Service- 
Oriented  Architecture  (SOA).  While  core  specifications  upon  which  WS-F  is  reliant  have 
achieved  OASIS  recognition  (WS-Security,  WS-SecurityPolicy,  WS-Trust),  WS-F  itself 
has  yet  to  achieve  standardization.  As  WS-F  relies  on  STS,  the  WS-Trust  model  will  be 
used  to  illustrate  how  authentication  is  performed  using  the  WS-F  standard. 

Figure  11  depicts  the  STS  authentication  process  [39].  A  user  requires  a  service 
from  an  SP  residing  in  a  separate  trust  domain.  To  access  the  desired  service,  he 
willrequire  a  security  token  from  his  AO(User)/STS  provider  and  an  access  token  from 
the  AO(SP)/STS  provider  that  governs/resides  in  the  target  trust  domain  which  the  SP 
recognizes.  The  user  proceeds  to  obtain  his  security  token  from  AO(User),  as  seen  in  step 
one.  This  is  achieved  through  a  pre-determined  authentication  means.  Because  both  AOs 
have  an  on-going  trust  relationship,  the  security  token  presented  to  the  other  AO  by  the 
user  is  accepted  in  step  two,  and  an  access  token  is  granted  to  the  user  in  step  three.  The 
access  token  is  subsequently  presented  to  the  SP  in  step  4  for  access  to  the  specified 
resource. 
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Figure  1 1 .  WS-F  authentication  Process  Flow  Diagram  [After  39] 

6,  Evaluation  Criteria 

To  determine  the  best-fit  framework  in  support  of  the  NRNS  component  of  the 
NAF,  the  following  criteria  have  been  derived,  based  upon  requirements  set  forth  by  the 
NAF. 


a.  Fit-for-purpose 

The  selected  framework  must  be  fit-for-purpose,  supporting  the 
deployment  characteristics  of  the  NAF.  These  include  supportability  for  NRNS  tokens, 
and  use  of  the  NAF  as  a  second  authentication  factor  to  the  established  SINGPASS 
infrastructure. 


b.  Standards-based 

The  selected  framework  must  be  based  upon  established  standards.  The 
availability  of  a  certification  service  is  an  advantage.  Differentiation  is  made  with 
dependence  upon  a  standard  and  actual  accreditation. 
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c.  Interoperable 


The  selected  framework  must  be  able  to  accommodate  and  integrate  with 
existing  and  future  standards/frameworks. 

d.  Ease-of-use 

The  selected  framework  must  be  usable  for  the  majority  of  the  population, 
presenting  the  least  inconvenience  in  terms  of  hardware  and  software  reliance. 

7.  Evaluation  and  Analysis 

Each  framework  was  assessed  based  on  the  stated  criteria,  with  the  results 
summarized  in  Table  2. 

a.  OpenID 

OpenID,  as  a  complete  authentication  protocol  standard,  will  add  an 
additional  layer  of  complexity  when  integrated  into  the  existing  SINGPASS  system.  A 
user  will  not  only  have  to  supply  his  SINGPASS  password  but  additionally  will  have  to 
input  the  required  URL/XRI-based  identifier  and  any  subsequent  token  required  of  the 
authentication  process  proper.  Current  implementations  rely  upon  passwords  for 
authentication.  Although  this  does  not  exclude  the  option  of  using  other  tokens,  the 
dearth  of  any  actual  implementations  will  continue  to  render  OpenID  suspect  in  this  area. 
While  OpenID  is  based  upon  XRI,  OpenID  itself,  as  a  standard,  lacks  third-party 
accreditation.  This  deficiency  may  be  mitigated  by  the  open-source  nature  of  the 
standard,  akin  to  JAVA,  whereby  its  advancement  is  dependent  upon  a  community  of 
developers.  In  terms  of  interoperability,  not  being  XML-based,  as  compared  to  SAME 
and  WS-E,  may  limit  its  extensibility  as  well  as  interoperability.  The  additional 
complexity  involved  should  OpenID  be  adopted  may  nullify  its  simplicity  and  ease-of- 
use,  as  will  the  possible  use  of  hardware  tokens  for  authentication.  URLs  and  XRIs  are 
also  not  easily  memorized  and  may  require  a  secondary  management  tool,  an  I-card  being 
one  option. 
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b.  Infocard 


Hardware  tokens  do  not  have  a  software-based  alternative  that  ean  be 
implemented  as  an  I-eard,  nor  ean  hardware  tokens  be  supported  as  a  Managed  Card.  In 
its  eurrent  implementation,  Infoeard  only  supports  the  X.509  and  Kerberos  standards 
[36].  This  demands  a  separate  framework  be  implemented  in  addition  to  Infoeard  to 
manage  hardware  tokens.  That  Infoeard  is  built  upon  WS*  standards  allows  for  some 
interoperability.  The  usability  and  eorresponding  ease-of-use  of  a  eard  seleetor  is 
dependent  upon  the  aetual  interfaee  presented.  The  requirement  for  the  installation  of 
eard  seleetor  software  is  a  substantial  additional  requirement  when  eompared  to  the  other 
frameworks  but  may  well  serve  as  a  convenient  tool  for  the  management  of  digital 
certificates  as  a  managed  card,  complementing  PKI. 

c.  SAML 

SAML  does  not  specify  the  authentication  method  but  provides  a  means 
whereby  assertions  can  be  transmitted  between  AOs,  thus  supporting  one  of  the  key 
required  characteristics  of  the  use  case  in  Chapter  II.  It  is  an  established  standard, 
endorsed  by  OASIS,  and  adopted  by  numerous  countries  [40]-[42]  as  part  of  their 
identity  management  infrastructure.  Being  XML-based,  SAML  is  expected  to  be 
interoperable  with  like  systems.  An  official  certification  body  also  exists  to  ensure 
products  comply  with  the  SAML  standard.  There  exist  specifications  that  integrate 
SAML  with  foundational  WS*  standards  other  than  WS-F.  The  use  of  SAML  is 
transparent  to  the  user,  leveraging  on  currently  existing  HTTP  request/redirect  protocol 
for  data  exchange. 

d.  WS-F 

WS-F  provides  similar  functionality  to  SAML;  although  it  has  yet  to  be 
ratified  by  OASIS,  it  is  in  the  process.  The  complexity  involved  in  realizing  WS-F,  being 
reliant  on  numerous  foundational  building  blocks,  permits  it  greater  extensibility,  not 
least  of  which  is  its  Web  services  nature.  Products  offering  WS-F  will  also  implement 
SAML;  that  implementation  does  remove  the  differences  between  the  two  to  a  degree 
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[43].  The  use  of  WS-F  is  likewise  transparent  to  the  user,  but  is  more  suited  to 
applieations  that  evoke  Web  serviees,  an  arehitecture  that  has  yet  to  be  fully  established, 
though  is  expected  to  be  further  developed  in  the  future  [44], 

Table  2.  Authentication  Framework  Comparison 


OpenID 

Infocard 

SAML 

WS-F 

Fit-for- 

purpose 

Y 

Y 

Standards- 

based 

Y 

Y 

Y 

Y 

Accredited 

Open-Source 

Y 

In-process 

Interoperable 

Y 

Y 

Ease-of-Use 

Dependent 

Y 

Y 

From  the  results  of  the  analysis,  it  is  evident  that  SAML  is  the  framework 
of  choice,  with  WS-F  as  a  credible  alternative. 

D,  SUMMARY 

In  this  chapter,  the  characteristics  of  various  identity  frameworks  have  been 
detailed,  discussed,  and  compared  as  a  means  of  selecting  the  best  framework  to 
implement  the  National  Authentication  Framework.  Inherent  characteristics  of  the 
selected  frameworks  will  serve  as  the  basis  for  infrastructure  deployment,  system 
implementation,  and  future  development,  underlining  the  importance  of  ensuring  that  the 
selected  framework  not  only  meets  current  requirements  but  also  will  be  sufficiently 
extensible  to  meet  future  needs.  Public  Key  Infrastructure  is  a  well-established 
framework  that  will  provide  for  non-repudiation.  For  non-repudiation  non-supporting 
authentication,  SAML  is  the  framework  of  choice.  The  next  chapter  will  delve  into 
greater  detail  as  to  how  SAML  will  realize  the  baseline  use  case. 
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V.  NAF  IMPLEMENTATION  MODEL 


A,  OVERVIEW 

Chapter  IV  established  the  basis  for  the  seleetion  of  SAML  as  the  standard  for  the 
implementation  of  the  non-repudiation  non-supporting  infrastrueture  of  the  NAF.  The 
realization  of  the  use  ease  as  speeified  in  Chapter  II  will  be  based  upon  features  organie 
to  SAML.  This  ehapter  will  provide  details  as  to  how  eaeh  seleeted  feature  will  realize  a 
eertain  aspeet  of  the  use  ease,  and  will  eonelude  with  an  illustration  of  how  the  various 
features  eonverge  to  realize  the  use  ease. 

B,  NAF  SAML  PROFILE 

1.  Overview 

At  its  highest  layer  of  abstraetion,  SAML  speeifies  profiles  to  fulfill  eertain 
funetionalities  required  during  authentieation.  The  Web  Browser  SSO  Profile  (WBSP), 
whieh  dictates  the  interactions  between  the  user,  SP,  and  AO  in  an  authentication  process, 
will  first  be  described,  as  per  the  prescribed  standard  as  endorsed  by  OASIS.  Thereafter, 
key  features  and  attributes  of  SAML  necessary  to  enhance  the  functionality  of  the  WBSP 
for  the  NAF  will  be  discussed. 

2.  Web  Browser  SSO  Profile 

The  SAML  v2.0  Technical  Overview  [45]  describes  how  a  user  authenticates  to 
an  SP  via  the  WBSP.  Underlying  the  transaction  is  the  ubiquitous  Hypertext  Transfer 
Protocol  (HTTP),  wherein  its  relationship  with  SAML  is  specified  as  part  of  the  SAML 
Bindings  abstraction.  The  choice  of  an  SP-initiated  process  is  in  sync  with  current 
practice  whereby  a  user  navigates  to  the  SP  page  to  initiate  authentication.  This  is 
opposed  to  an  AO-initiated  process,  where  the  user  navigates  first  to  an  AO,  prior  to 
accessing  the  SP.  The  WBSP,  as  extracted  from  the  SAML  standard,  is  detailed  below 
(Figure  12). 
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USER 


Figure  12.  Web  Browser  SSO  Profile.  After  [45] 

A  user  attempts  to  access  a  resource  but  is  denied  by  the  SP  pending 
authentication,  shown  in  step  one.  In  step  two,  the  SP  sends  an  HTTP  Redirect  response 
to  the  user’s  Web  browser,  specifying  the  Uniform  Resource  Identifier  (URl)  of  the  AO, 
appended  with  an  <AuthnRequest>  message  encoded  as  a  URL  query  variable.  The 
user’s  browser,  upon  receipt  of  the  HTTP  Redirect  response,  issues  an  HTTP  Get  request 
to  the  AO’s  authentication  service,  with  the  same  <AuthnRequest>  appended.  Step  three 
sees  the  AO  interpret  the  <AuthnRequest>  to  determine  the  specific  requirements  of  the 
SP  for  authentication  and  thereafter  proceeds  to  authenticate  the  user  through  a  token 
presented  by  the  user,  as  shown  in  step  four.  Upon  positive  authentication  in  step  five,  the 
AO  proceeds  to  build  an  assertion  and  returns  this  assertion,  placed  in  a  <Response> 
message  as  an  HTML  form  to  the  user’s  browser.  This  HTML  form  is  subsequently  sent 
to  the  user  as  a  redirect  to  be  forwarded  to  the  relying  SP  as  an  HTTP  POST  request, 
depicted  in  step  six.  The  SP  validates  the  authenticity  of  the  assertion  and  thereafter 
proceeds  to  permit  access  to  the  resource  as  requested  by  the  user,  in  step  seven. 
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3,  Proxy  Authentication  Operator 


The  <AuthnRequest>  message,  as  depleted  in  the  previous  section,  is  the  key 
message  sent  by  the  SP  to  initiate  an  authentication  request  to  an  AO.  The 
<AuthnRequest>  message  contains  substantial  information  specifying  the  authentication 
context  required  in  order  for  the  user  to  gain  access  to  the  requested  service.  Critical 
contextual  factors  include  the  level  or  strength  of  the  authentication  method,  as  specified 
by  the  <RequestedAuthnContext>  subfield,  the  SP-defined  user’s  transactional  ID  as 
specified  in  the  <NameIDPolicy>  subfield,  and  the  list  of  recognized  AOs  with  regards  to 
the  SP,  as  specified  in  the  <Scoping>  subfield.  A  notable  characteristic  of  the  use  case 
developed  in  Chapter  II  is  the  ability  of  the  SP’s  AO  (AO(SP))  to  seek  user 
authentication  from  the  user’s  AO  (AO(User)).  This  capability  is  realized  by 
specifications  enclosed  within  the  <Scoping>  subfield,  which  allows  for  the  actual 
authentication  of  the  user  to  be  transferred  to  a  secondary  AO,  a  transaction  known  as 
proxying. 

Since  AO(User)  may  not  be  similar  to  the  AO(SP),  there  is  a  need  for  the  AO(SP) 
to  seek  an  assertion  from  AO(User)  and,  thereafter  transfer  the  assertion  generated  by  the 
AO(User)  to  the  SP.  This  is  realized  through  AO(SP)  generating  an  <AuthnRequest> 
message  of  its  own  and  once  more  redirecting  the  user  to  AO(User).  The  assertion 
generated  from  AO(User)  is  first  received  by  the  AO(SP),  which  proceeds  to  extract  the 
assertion  from  the  HTTP  Post  request,  repackage  the  assertion  into  a  form  recognizable 
by  the  SP,  and  thereafter  forward  the  assertion  once  more  as  an  HTTP  Post  request.  This 
functionality  is  only  possible  if  certain  conditions  are  met  within  the  <Scoping>  subfield. 
The  first  is  for  the  <ProxyCount>  subfield  within  that  of  <Scoping>  to  be  set  to  more 
than  0.  This  figure,  as  obtained  from  the  SP,  specifies  the  number  of  proxy  operations 
allowed  by  the  SP  for  authentication.  The  user’s  AO  must  also  reside  in  a  list  documented 
in  the  <IDPList>  subfield  as  the  list  of  AOs  that  the  SP  trusts  to  provide  authentication. 
The  token  used  by  the  AO  also  has  to  conform  to  the  minimal  standard  imposed  by  the 
<RequestedAuthnContext>  element  as  stated  in  the  <AuthnContextClassRef>  and  its 
<Comparison>  subfield.  The  <AuthnContextClassRef>  defines  the  type  of  token  with  the 

least  amount  of  assurance  acceptable  for  the  authentication.  The  <Comaprison>  field  has 
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a  value  of  “minimum,”  indicating  that  the  actual  authentication  token  used  cannot  be 
lower  in  assurance  than  that  set  in  <AuthnContextClassRef>.  The  relationship  between 
the  messages  and  subfields  described  in  this  paragraph  are  summarized  in  Figure  13. 


<AuthnRequest> 

<saml :  Subject> 

<NameID> 

<SPNameQualifier> 

<SPProvidedID> 

<NameIDPolicy> 

<Format> 

<RequestedAuthnContext> 

<AuthnContextClassRef> 

<Comparison> 

<Scopmg> 

<ProxyCount> 

<IDPList> 

Figure  13.  <AuthnRequest>  Fields  Extract.  After  [46] 


4,  Transient  Identifier 

An  identifier  is  attached  to  an  <AuthnRequest>  to  associate  the  user,  or  subject,  of 
the  authentication.  To  ensure  user  privacy,  a  one-time  use  transient  identifier  is  proposed 
over  the  use  of  a  persistent  identifier.  A  persistent  identifier,  while  limited  to  only 
between  that  of  the  SP  and  the  AO,  may  allow  for  the  unwarranted  collation  of  past  and 
present  authentication  attempts  by  the  user.  A  transient  identifier,  being  single-use,  is 
only  valid  for  one  instance  of  an  authentication  transaction  and  requires  regeneration  for 
each  subsequent  transaction.  With  reference  to  Figure  13,  the  transient  identifier  is  a 
pseudorandom  number  generated  by  the  SP  and  appended  to  an  <AuthnRequest>  via  the 
<SPProvidedID>  field.  The  SP  also  sets  the  <SPNameQualifier>  with  its  own  unique  ID, 
and  specifies  that  the  identifier  used  is  a  transient  one  in  <Format>.  The  setting  of  the 
<Format>  field  allows  the  receiving  AO  to  know  that  the  <SPProvidedID>  is  transient  in 
nature  and  cannot  be  relied  upon  for  subsequent  authentication  requests,  where  a  new 
identifier  will  be  expected.  In  a  proxying  relationship,  the  same  <SPProvidedID>  is 

expected  to  remain  constant  for  the  instance  of  the  authentication  transaction. 
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5.  Response 


The  AO,  having  verified  a  user’s  submitted  token,  issues  the  assertion  in  a 
<Response>  message,  which  is  subsequently  redirected  to  the  requesting  SP.  A 
<Response>  message  is  essentially  a  carrier  for  the  assertion.  The  assertion  will  contain 
the  following  attributes  as  captured  in  Figure  14:  <Version>  states  the  version  of  the 
assertion,  by  default  being  2.0.  The  <ID>  is  a  unique  one-time  randomly  generated 
identifier  for  the  specific  assertion,  minimally  128  bits  in  length.  <lssuelnstant>  states  the 
time  that  the  assertion  was  generated.  <Issuer>  captures  the  identifier  of  the  submitting 
AO.  <ds:Signature>  is  required  for  authentication  of  the  assertion  itself,  originating  from 
a  credible  source  through  the  application  of  a  digital  signature.  <Subject>  contains  the 
transient  identifier  issued  originally  by  the  requesting  SP. 


<Response> 

<Assertion> 

<Version> 

<ID> 

<lssuelnstant> 

<Issuer> 

<ds:Signature> 

<Subject> 


Figure  14.  <Response>  Fields  Extract.  After  [46] 


C.  USE  CASE  REALIZATION 

This  section  depicts  the  basis  use  case,  developed  in  Chapter  II,  being  realized  by 
components  of  SAME  v2.0. 
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Figure  15.  Authentication  Use  Case 


1.  Conversation  #1;  The  user  submits  the  first  legacy  authentication  token 
(SINGPASS  password)  to  the  SP,  which  proceeds  to  authenticate  this  first  token.  Should 
the  token  be  invalid,  the  connection  is  immediately  terminated. 

2.  Conversation  #2:  Should  the  token  be  valid,  the  SP  issues  an  HTTP 
Redirect  response  to  the  user’s  browser  (Browser(U)),  directing  the  user  to  AO(SP)  with 
an  <AuthnRequest>  message  appended.  The  AO(SP)  authentication  server  receives  the 
<AuthnRequest>;  from  the  analysis  of  the  <lDPList>  field,  it  determines  the  acceptable 
AOs  that  the  SP  authorizes  for  the  generation  of  an  assertion  and  generates  a  Web  Page 
that  allows  the  user  to  select  the  appropriate  authorized  AO.  Note  that  the  AO(SP)  would 
be  in  this  list  as  well  because  the  AO(SP)  would  not  have  any  indicator  regarding 
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whether  any  particular  user  has  a  relationship  with  it,  and  AO(SP)  therefore  cannot 
automatically  initiate  the  establishment  of  a  second-factor  authentication  process  with  the 
user. 

3.  Conversation  #3:  The  user  selects  the  appropriate  AO(User).  If  AO(User) 
is  AO(SP),  then  AO(SP)  will  continue  with  authentication  and  the  generation  of  the 
assertion.  If  AO(User)  is  another  entity,  the  AO(SP)  will  now  transit  into  the  role  of  a 
proxying  AO  and  issue  an  HTTP  Redirect  response  once  more  to  Browser(U)  and  direct 
the  user  to  AO(User)  with  an  <AuthnRequest>  appended. 

4.  Conversation  #4:  The  user  proceeds  to  submit  his  token  and  any  other 
necessary  attributes  (e.g.,  identifier  unique  to  AO(User))  to  the  AO(User)  for 
authentication.  The  AO(User),  having  verified  the  identity  of  the  user,  will  generate  an 
assertion  in  a  <Response>  message  and  return  the  user  to  AO(SP)  via  an  HTML  form. 

5.  Conversation  #5:  AO(SP)  extracts  the  assertion  and  repackages  it  into  a 
form  unique  to  itself  and  the  relying  SP,  and  returns  the  assertion  in  a  <Response> 
message  via  an  HTML  form  to  the  SP.  Note  that  AO(User)  remains  as  the  originator  of 
the  assertion.  AO(SP)  merely  edits  the  necessary  fields  in  the  <Response>  message  to 
enable  communication  between  it  and  the  SP. 

6.  Conversation  #6;  The  SP,  having  received  the  assertion,  proceeds  to  allow 
the  user  access  to  the  requested  service. 

D.  SUMMARY 

In  this  chapter,  it  has  been  shown  that  SAML  has  many  built-in  features  that 
support  the  realization  of  the  use  case.  Among  the  more  pertinent  features  are  the  ability 
to  proxy  an  authentication  request,  to  define  a  transient  identifier,  and  to  dictate  the  AOs 
and  token  type  assurance  levels  suitable  to  the  supported  transaction.  That  SAML  also 
defines  profiles  encompassing  supporting  protocols  shows  how  it  can  be  easily  realized 
with  current  technology.  SAML  is  sufficiently  robust  to  meet  the  requirements  of  future 
challenges,  being  organically  highly  extensible.  The  choice  of  SAML  as  the  basis 
standard  ensures  that  the  NAF  will  be  effectively  and  efficiently  realized. 
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VI.  CONCLUSION 


A,  OVERVIEW 

The  NAF  is  an  ambitious  project,  not  just  in  terms  of  scale,  but  also  in  terms  of 
scope.  There  has  yet  to  be  a  similar  effort  at  implementing  a  national  two-factor 
authentication  system  with  the  amount  of  choice  available  to  the  user.  In  so  doing,  several 
important  lessons  can  be  derived  which  will  be  elaborated  upon  in  this  chapter.  The 
chapter  will  conclude  with  suggestions  for  further  research  into  this  novel  effort. 

B,  LESSONS  LEARNED:  COMPROMISES 

In  stating  the  requirements  for  the  NAF,  two  elements  stand  out  that  have  had 
broad  implications  on  the  eventual  implementation  model.  Firstly,  the  NAF  is  to  be 
implemented  in  concert  with  the  operational  single-factor  authentication  system. 
Secondly,  non-repudiation  is  a  criterion  for  the  system.  This  section  will  detail  the 
implications  of  these  two  system  requirements. 

1.  Co-existence 

The  legacy  password-based  SINGPASS  authentication  system,  still  currently  in 
use,  will  continue  to  serve  as  the  first  authentication  factor.  Support  for  SINGPASS 
remains  the  domain  of  a  single  operator,  contracted  by  the  government  for  its  operation. 
While  the  operation  of  SINGPASS  remains  distinct  from  the  SAML-based  second-factor 
authentication,  its  continued  existence  implies  that,  in  the  short  term,  the  NAF  would 
play,  at  best,  a  complimentary  role.  That  SINGPASS,  if  kept  in  its  current  form, 
diminishes  the  practicality  of  implementing  a  non-SAML  NAF  framework;  for  instance, 
the  implementation  of  OpenID  (non-SAML)  would  require  the  user  to  input  a  second 
what-you-know  identifier  in  addition  to  that  already  required  for  SINGPASS.  The 
benefits  of  the  NAF  to  the  user  are  also  diminished,  as  the  user  would  still  be  required  to 
use  the  services  of  both  the  government-dictated  Authentication  Operator  (AO)  for 
SINGPASS,  and  another  AO  for  the  second  factor.  The  operator  for  SINGPASS  is  also 
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placed  at  a  competitive  advantage  over  its  peers.  Being  the  long-standing  solution,  it  not 
only  has  the  advantage  of  reputation,  but  will  be  well  placed  to  offer  synergistic  services 
incorporating  both  the  first  and  second  authentication  factors  in  spite  of  any  technieal  and 
operational  differenees  between  SINGPASS  and  the  NAF.  While  the  continuanee  of 
SINGPASS  may  have  very  mueh  been  a  contractual  issue,  that  the  government  eontinues 
to  leverage  on  a  proprietary  legaey  system  while  proposing  and  pushing  for  an  enterprise 
one  may  also  diminish  the  aeceptance  of  the  NAF  in  the  eyes  of  possible  private-sector 
users,  particularly  the  banking  industry,  which  already  has  2FA  authentication  systems  in 
plaee.  This  may  result  in  the  authentieation  landscape  remaining  status  quo  for  the  user 
exeept  for  the  addition  of  yet  another  token  for  purposes  of  government  services.  It  is 
recognized  that  SINGPASS  would  play  a  role  during  the  transition  phase  as  part  of  the 
roll-out  of  the  NAF.  Once  the  implementation  issues  for  the  NAF  have  been  resolved  and 
the  schedule  put  in  place  for  its  roll-out,  however,  it  would  be  helpful  for  the  government 
to  announce  the  road  map  for  the  eventual  dissolution  of  SINGPASS  and  for  the  full 
transition  to  the  NAF,  wherein  both  tokens  used  for  authentication  would  be  a  result  of 
the  user’s  choiee.  That  would  provide  the  impetus  for  wider  adoption  of  the  NAF  and  the 
full  realization  of  the  system’s  stated  objective. 

2.  Non-repudiation 

Among  the  requirements  set  forth  for  the  NAF  is  that  of  non-repudiation  for 
aceess  to  certain  services.  This  requirement  for  non-repudiation,  though  entirely  logical, 
immediately  limits  the  type  of  token  used  to  that  of  the  asymmetrical  cryptographic  type. 
With  such  a  requirement,  each  user  of  government  services  will  be  required  to  have  in  his 
possession  an  asymmetrie  eryptographie  token,  making  such  a  token  the  default  choiee 
for  users  and  thus  limiting  the  take-up  rate  of  other  token  types.  This  brings  up  the 
relative  costs  of  using  other  token  types,  whieh  may  make  owning  other  tokens 
financially  and  practically  infeasible.  This  remains,  in  public  policy  parlance,  a  wicked 
problem.  The  requirement  for  non-repudiation  cannot  be  rescinded  easily,  as  doing  so 
would  result  in  an  Integrity  issue.  Yet  continuing  with  the  existence  of  the  requirement 
for  non-repudiation  would  limit  the  market  for  non-asymmetric  cryptographic  token 
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types.  It  is  then  best  left  to  the  aeademie  eommunity  to  devise  an  alternate  token  type  that 
also  provides  non-repudiation  as  a  direet  eompetitor  to  that  of  an  asymmetrie 
eryptographie  token. 

C.  FUTURE  RESEARCH 

As  of  Deeember  2009,  the  NAF  is  in  its  eonsultative  stage  whereby  eomments 
and  proposals  are  being  sought  from  both  industry  and  aeademia.  One  area  in  whieh  work 
will  be  needed  is  a  study  of  the  aetual  implementation  model  that  is  adopted  and  the  basis 
for  the  seleetion  of  the  various  underlying  teehnologies  that  support  the  implemented 
model.  Next,  a  post-implementation  review  of  the  implemented  system  would  also  yield 
important  lessons  that  would  be  useful  for  other  organizations  that  may  wish  to  embark 
on  a  similar  type  projeet. 

D,  SUMMARY 

The  aim  of  this  thesis  was  to  propose  an  implementation  model  for  the  NAF.  A 
baseline  use  ease  was  first  developed  to  outline  the  relationships  between  the  user,  the  SP 
and  the  AO,  to  be  used  as  the  main  referenee  in  the  applieation  of  supporting 
teehnologies.  Thereafter,  a  survey  of  eurrent  token  types  was  eondueted,  with  eaeh  token 
type  being  assessed  for  its  suitability  for  use  in  the  NAF,  suseeptibility  to  seeurity  threats, 
and  provision  of  non-repudiation  being  major  eriteria.  The  asymmetrie  eryptographie 
token  type  has  been  seleeted  for  use  where  non-repudiation  is  required,  and  the  OTP  and 
Out  of  Band  token  has  been  seleeted  for  use  where  non-repudiation  is  not  required. 
Following,  five  leading  identity  frameworks  were  assessed  for  their  suitability.  The 
frameworks  were  assessed  based  on  whether  they  were  fit-for-purpose,  were  standards- 
based,  were  interoperable,  and  were  easy-to-use.  SAME  emerged  as  the  framework  of 
ehoiee  where  non-repudiation  was  not  required,  while  PKI  would  serve  as  the  framework 
where  non-repudiation  was  required.  How  SAME  would  be  used  to  meet  the 
requirements  of  the  AO  was  also  deseribed  in  detail,  partieularly  the  ability  for  proxy 
authentieation  and  the  use  of  transient  identifiers.  It  was  observed  that  several 
requirements  for  the  NAF  have  had  an  asymmetrie  effeet  on  the  eventual  implementation 
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model,  particularly  the  need  for  co-existence  with  a  legacy  system  and  the  need  for  non¬ 
repudiation.  It  has  been  suggested  that  the  legacy  system  be  retired  as  early  as  possible 
and  that  an  alternative  token  type,  which  would  provide  non-repudiation,  be  worked  on. 
As  part  of  future  research,  it  would  be  extremely  instructive  to  continue  to  follow  the 
development  of  the  NAF  to  its  conclusion,  because  much  can  be  learned  and  applied  to 
subsequent  exercises  of  the  same  nature. 
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